f2fs: fix fsck inconsistency caused by FGGC of node block
- Published
- Last modified
- Where the record stands: published, rejected by its publisher, or superseded by another id.What do these mean? →
- published
- Whether CISA lists it in its Known Exploited Vulnerabilities catalog: proof that attackers are using it.What do these mean? →
- Not listed in CISA KEV
- How many real-world setups can hit the bug, from the vendor's advisory and CISA data. It does not know your setup.What do these mean? →
- Specific setups only
- Fix
- Fixed in 6.6.160, 6.12.114, 6.18.30, 7.0.7
- Whether working attack code is public (Exploit-DB, Metasploit, Nuclei or GitHub). Public code makes attacks easier.What do these mean? →
- None on Exploit-DB, Metasploit or GitHub
Summary
In the Linux kernel, the following vulnerability has been resolved: f2fs: fix fsck inconsistency caused by FGGC of node block During FGGC node block migration, fsck may incorrectly treat the migrated node block as fsync-written data. The reproduction scenario: root@vm:/mnt/f2fs# seq 1 2048 | xargs -n 1 ./test_sync // write inline inode and sync root@vm:/mnt/f2fs# rm -f 1 root@vm:/mnt/f2fs# sync root@vm:/mnt/f2fs# f2fs_io gc_range // move data block in sync mode and not write CP SPO, "fsck --dry-run" find inode has already checkpointed but still with DENT_BIT_SHIFT set The root cause is that GC does not clear the dentry mark and fsync mark during node block migration, leading fsck to misinterpret them as user-issued fsync writes. In BGGC mode, node block migration is handled by f2fs_sync_node_pages(), which guarantees the dentry and fsync marks are cleared before writing. This patch move the set/clear of the fsync|dentry marks into __write_node_folio to make the logic clearer, and ensures the fsync|dentry mark is cleared in FGGC.
Timeline
- CVE published
- Record last updated
Affected versions
- Linux Linux
Version range not reported
- Linux Linux
4.7
- KernelLinux
From 4.7.0 · fixed in 6.6.160; From 6.7.0 · fixed in 6.12.114; From 6.13.0 · fixed in 6.18.30; From 6.19.0 · fixed in 7.0.7
References 6
git.kernel.org
Questions about CVE-2026-46175
What does this mean?
During foreground garbage collection in the F2FS filesystem, a node block can be moved, and fsck may then wrongly flag an inode as inconsistent. The inode was already checkpointed, but its dentry bit is still set because the moved node block is treated as fsync-written data.Source: git.kernel.org
Am I affected, and how do I check?
The facts list Linux kernel ranges from 4.7.0 up to (not including) 6.6.160, 6.7.0 up to 6.12.114, 6.13.0 up to 6.18.30, and 6.19.0 up to 7.0.7. To check a system, look at the kernel version with uname -r and compare it to those ranges. The problem only arises when foreground GC migrates a node block on an F2FS volume.Source: git.kernel.org
What should I do about it?
Upgrade to a fixed kernel for your release line: 6.6.160, 6.12.114, 6.18.30, or 7.0.7 or later. No fix-free workaround is listed in the facts.Source: git.kernel.org
Is it being exploited?
It is not in CISA's Known Exploited Vulnerabilities catalog, and CISA's SSVC assessment does not mark exploitation as active. That does not mean it has not been attacked: vendors and researchers can report attacks before CISA lists them. No public exploit code is tracked.Source: cve.now feed data