CVE-2026-89836: f2fs: fix folio_nr_pages() race after put in large folio invalidate
In the Linux kernel, the following vulnerability has been resolved:
f2fs: fix folionrpages() 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 nrpages before drop the refcount and foliolock.
f2fsgetreaddatafolio() calls f2fsfolioput() before folionrpages() 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->ipages, 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] xasload at ffffffe52d1f42a4 #1 [ffffffc08ef2b900] findgetentries at ffffffe52c185798 #2 [ffffffc08ef2bb60] truncateinodepagesrange at ffffffe52c19e83c #3 [ffffffc08ef2bbc0] truncateinodepagesfinal at ffffffe52c19ec2c #4 [ffffffc08ef2bc20] f2fsevictinode at ffffffe52c4c8400 #5 [ffffffc08ef2bcc0] evict at ffffffe52c2de9f4 #6 [ffffffc08ef2bd00] iput at ffffffe52c2db1b4 #7 [ffffffc08ef2bd30] dentryunlinkinode at ffffffe52c2d7204 #8 [ffffffc08ef2bd50] dentrykill at ffffffe52c2d3dcc #9 [ffffffc08ef2bd80] dput at ffffffe52c2d3c3c #10 [ffffffc08ef2bda0] fput at ffffffe52c2b0a7c #11 [ffffffc08ef2bde0] fput at ffffffe52c2b1034 #12 [ffffffc08ef2bdf0] taskworkrun at ffffffe52beea200 #13 [ffffffc08ef2be20] exittousermodeloop at ffffffe52bfbc17c #14 [ffffffc08ef2be80] el0svc at ffffffe52d1f8e54 #15 [ffffffc08ef2beb0] el0t64synchandler at ffffffe52d1f8d10
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
Linux kernel (v6.18 based Android system)to a version that resolves this vulnerability.Fixed in v6.18Patch f2fs: fix folio_nr_pages() race after put in large folio invalidate - Compensating control
As an immediate mitigation while applying the kernel fix, reduce the likelihood of triggering the folio race by avoiding concurrent large-folio invalidate/split operations (e.g., minimize heavy filesystem truncate/reclaim activity that can race with f2fs large folio invalidation on the v6.18-based system).
Event History
Frequently Asked Questions
Which deployments are most likely to encounter this issue?
The issue was observed on a v6.18-based Android system using f2fs. It concerns f2fs handling of large folios during page-cache invalidation.
What concurrent activity is required for the race to cause damage?
After f2fs unlocks and drops its folio reference, a concurrent truncate or folio split must shrink or free the compound folio before the invalidate range is calculated. This can leave split sub-folios behind in mapping->i_pages.
What signs indicate that a system may already be affected?
Reported consequences include livelock, bad page-state reports, stale xarray entries, and cases where folio->mapping no longer matches the mapping being truncated. Stack traces may involve xas_load, find_get_entries, or truncate_inode_pages_range.
How is the issue fixed?
The fix obtains the folio page count before dropping the folio reference and lock, preventing the invalidate range from being computed after concurrent folio changes. The supplied stable-kernel references are cc34df18da92f68f9b384c3ae95ad64be46cb5ee and 0dab71381f1b4d12dc2056f8bd5aaa9d93ce9082.