CVE-2026-89841 in Linux
Summary
by MITRE • 09/16/2026
In the Linux kernel, the following vulnerability has been resolved:
f2fs: only redirty pinned folios in redirty_blocks
redirty_blocks() pins folios with read_cache_folio() and then walks the same range again with filemap_lock_folio() to redirty them and drop the references it took.
Commit 5951fee46bef ("f2fs: Use a folio in redirty_blocks()") changed the second pass to a do/while loop. If read_cache_folio() fails before anything is pinned, page_idx does not advance but the cleanup loop still runs once.
If readahead has already populated the failed folio in page cache, that extra iteration finds it and folio_put_refs(folio, 2) drops one reference too many. Later drop_caches or reclaim can then report "BUG: Bad page state".
Only redirty the range that was pinned successfully.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Analysis
by VulDB Data Team • 09/16/2026
The vulnerability identified in the Linux kernel's F2FS file system stems from a logic error within the redirty_blocks function, specifically related to reference counting and folio management during block dirtying operations. The core issue arises when read_cache_folio fails to pin a folio before the subsequent cleanup loop executes. In this scenario, the page index does not advance because no successful cache operation occurred, yet the do-while loop continues for one additional iteration. This extra iteration attempts to access and manipulate a folio that was never successfully pinned by the initial read_cache_folio call. If the file system's readahead mechanism has already populated this specific folio in the page cache, the subsequent operations incorrectly assume ownership or responsibility for it, leading to an erroneous decrement of reference counts via folio_put_refs with a value of two instead of one.
This incorrect reference count manipulation results in a use-after-free condition where the kernel drops references too many times for a given memory object. The immediate operational impact is visible when subsequent system activities such as dropping caches or performing memory reclaim operations attempt to interact with these corrupted page states. These interactions trigger a BUG: Bad page state error, which typically causes the affected process to crash and can potentially lead to broader system instability if not contained by kernel panic settings. This flaw represents a classic instance of improper resource management where failure handling paths do not correctly align with success path assumptions regarding object lifecycle and reference ownership.
From a vulnerability classification perspective, this issue maps directly to CWE-362, which describes concurrent execution using shared resources with inadequate synchronization, although in this specific context it is more accurately characterized as CWE-415, Double Free of a Resource, or CWE-787, Out-of-bounds Write if the reference count underflow leads to memory corruption. The ATT&CK framework does not have a direct technique for kernel internal logic errors of this nature unless they are exploited for privilege escalation, but it falls under the broader category of exploitation potential through local denial of service or potentially arbitrary code execution depending on how the corrupted page state is leveraged by other subsystems.
Mitigation strategies primarily involve applying the upstream Linux kernel patch that corrects the loop logic to ensure redirtying only occurs for ranges where folios were successfully pinned. System administrators should monitor their systems for BUG: Bad page state messages in dmesg logs, which serve as indicators of this specific memory corruption event. Keeping the F2FS driver and associated VFS layer components updated is critical, as older versions retain this logic flaw. Additionally, developers reviewing similar file system code paths should ensure that error handling routines strictly validate whether resources were successfully acquired before attempting to release them, thereby preventing reference count mismatches that compromise kernel memory integrity.