CVE-2026-89841: f2fs: only redirty pinned folios in redirty_blocks
In the Linux kernel, the following vulnerability has been resolved:
f2fs: only redirty pinned folios in redirtyblocks
redirtyblocks() pins folios with readcachefolio() and then walks the same range again with filemaplockfolio() to redirty them and drop the references it took.
Commit 5951fee46bef ("f2fs: Use a folio in redirtyblocks()") changed the second pass to a do/while loop. If readcachefolio() fails before anything is pinned, pageidx 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 folioputrefs(folio, 2) drops one reference too many. Later dropcaches or reclaim can then report "BUG: Bad page state".
Only redirty the range that was pinned successfully.
Affected Software
Event History
Frequently Asked Questions
Which systems are affected in practice?
The issue is in the Linux kernel's f2fs code. It is relevant to systems using the f2fs filesystem and exercising the redirty_blocks() path.
What conditions trigger the reference-count error?
read_cache_folio() must fail before it pins any folios, while readahead has already populated the failed folio in the page cache. The cleanup loop can then process that folio despite no successful pin and drop one reference too many.
How can an administrator identify a system that has already encountered the issue?
Later cache dropping or memory reclaim can report "BUG: Bad page state" after the incorrect reference drop.
Is a fix available?
The vulnerability is described as resolved, and three Linux stable-tree fix references are provided. The supplied data does not identify the kernel versions containing those fixes.