CVE-2026-89836 in Linuxinfo

Summary

by MITRE • 09/16/2026

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

If you want to get best quality of vulnerability data, you may have to visit VulDB.

Analysis

by VulDB Data Team • 09/16/2026

The Linux kernel's F2FS file system contains a critical race condition within the large folio invalidation logic that can lead to severe stability issues including livelocks and corrupted page states. This vulnerability arises from an improper ordering of operations when handling compound folios, specifically in the f2fs_get_read_data_folio function during the process of invalidating data from the page cache. The core technical flaw involves calling f2fs_folio_put before invoking folio_nr_pages while managing a large folio that spans multiple pages. This sequence creates a dangerous window where the folio lock is released and the caller reference count is dropped prematurely, allowing concurrent operations such as file truncation or folio splitting to modify or free the compound folio structure before the invalidate range has been accurately computed based on the original page count.

The operational impact of this race condition manifests primarily through broken xarray slot status within the kernel's memory management subsystem. When a large folio is split or shrunk by a concurrent truncate operation while it remains in an inconsistent state, the resulting undersized invalidation range fails to properly clean up all associated sub-folios. This leaves stale entries in the mapping->i_pages structure that no longer correctly reflect the actual file size or memory layout. These orphaned xarray entries subsequently interact poorly with subsequent truncation and page reclaim operations, leading to scenarios where folio metadata such as the mapping pointer becomes mismatched against the active mapping context. In practical terms for Android systems running kernel version 6.18, this manifests as persistent livelocks that degrade system responsiveness and bad page state errors that can trigger kernel panics or require manual intervention to clear corrupted memory structures.

From a vulnerability classification perspective, this issue aligns with CWE-362 Concurrent Execution using Shared Resource with Improper Synchronization, commonly known as a race condition. The improper synchronization of reference counting and locking mechanisms allows external threads to alter shared data structures in an unsafe manner. Furthermore, the resulting state corruption can be mapped to ATT&CK technique T1499 Endpoint Denial of Service via resource exhaustion or instability, although this is typically unintentional rather than maliciously crafted. The root cause lies in the failure to maintain atomicity during critical sections where folio metadata and reference counts are modified concurrently with other kernel subsystems that rely on consistent state assumptions.

The resolution involves reordering the operations within f2fs_get_read_data_folio to ensure data integrity is preserved before releasing locks or references. Specifically, the fix mandates retrieving the nr_pages value prior to dropping the refcount and unlocking the folio. By capturing the page count while the folio remains locked and referenced, the kernel ensures that the invalidate range calculation reflects the true size of the compound folio at the moment of invalidation initiation. This prevents concurrent truncate or split operations from shrinking the structure beneath the current operation's expectations. To mitigate this vulnerability in affected systems, administrators should apply the latest stable Linux kernel updates that include this specific f2fs patch. For environments unable to update immediately, monitoring for signs of memory pressure anomalies or frequent inode eviction failures can serve as an early warning indicator, though no effective workaround exists other than avoiding heavy concurrent truncation and read operations on large files within F2FS partitions until the patch is deployed.

Responsible

Linux

Reservation

09/11/2026

Disclosure

09/16/2026

Moderation

accepted

CPE

ready

EPSS

0.00000

KEV

no

Activities

very low

Sources

Want to know what is going to be exploited?

We predict KEV entries!