CVE-2026-89836
CVE CVE-2026-89836EUVD EUVD-2026-80436Published 2026-09-16T10:31:10.000ZLast changed 2026-09-16T14:39:08.000ZCVSS 7.8
What the advisory describes
In the Linux kernel, the following vulnerability has been resolved: f2fs: fix folio_nr_pages() race after put in large folio invalidate Our v6.18 based Android system is continuely suffering livelock and bad page stat as shown in[1] which related to broken xarray slot status. By investigating big folio operations within f2fs, we find below races and fix it by get the nr_pages before drop the refcount and folio_lock. f2fs_get_read_data_folio() calls f2fs_folio_put() before folio_nr_pages() when invalidating a large folio from the page cache. That unlocks the folio and drops the caller reference, leaving a window where a concurrent truncate or folio split can shrink the compound folio or free it before the invalidate range is computed. An undersized range then leaves split sub-folios in mapping->i_pages, which can later interact badly with truncate and reclaim (stale xarray entries and bad page state when folio->mapping no longer matches the mapping being truncated). [1] PID: 2594 TASK: ffffff8169b81580 CPU: 7 COMMAND: "Thread-3" #0 [ffffffc08ef2b8a0] xas_load at ffffffe52d1f42a4 #1 [ffffffc08ef2b900] find_get_entries at ffffffe52c185798 #2 [ffffffc08ef2bb60] truncate_inode_pages_range at ffffffe52c19e83c #3 [ffffffc08ef2bbc0] truncate_inode_pages_final at ffffffe52c19ec2c #4 [ffffffc08ef2bc20] f2fs_evict_inode at ffffffe52c4c8400 #5 [ffffffc08ef2bcc0] evict at ffffffe52c2de9f4 #6 [ffffffc08ef2bd00] iput at ffffffe52c2db1b4 #7 [ffffffc08ef2bd30] dentry_unlink_inode at ffffffe52c2d7204 #8 [ffffffc08ef2bd50] __dentry_kill at ffffffe52c2d3dcc #9 [ffffffc08ef2bd80] dput at ffffffe52c2d3c3c #10 [ffffffc08ef2bda0] __fput at ffffffe52c2b0a7c #11 [ffffffc08ef2bde0] ____fput at ffffffe52c2b1034 #12 [ffffffc08ef2bdf0] task_work_run at ffffffe52beea200 #13 [ffffffc08ef2be20] exit_to_user_mode_loop at ffffffe52bfbc17c #14 [ffffffc08ef2be80] el0_svc at ffffffe52d1f8e54 #15 [ffffffc08ef2beb0] el0t_64_sync_handler at ffffffe52d1f8d10
Source: EUVD (ENISA), in the words of the advisory.
Products the advisory names
These come from the advisory itself, not from any check we performed.
- Linux — Linux patch: 0; 05e65c14ea59a401cec4284e9d612f9d5dc1b3f8 <0dab71381f1b4d12dc2056f8bd5aaa9d93ce9082; patch: 7.3-rc1; 7.0; patch: 7.2.5; 05e65c14ea59a401cec4284e9d612f9d5dc1b3f8 <cc34df18da92f68f9b384c3ae95ad64be46cb5ee
The versions shown are the advisory's own. Patchlage compares no version numbers and derives no judgement from them — which version is installed is something a person has to look up.
Carried in the product catalogue
An estate covering these products can be recorded in Patchlage. An advisory about them appears in the next morning's situation report.
- Linux — Linux
Does this concern one of your customers?
This page cannot answer that — it does not know your estate. Whoever has recorded their environments gets the answer the morning after publication, together with a paragraph they can forward to the customer unedited.
Try it for 28 daysPatchlage reports hits and suspected hits. About everything else this system says nothing — neither this page nor the situation report ever claims that an estate is safe.