f2fs: fix incorrect FI_NO_EXTENT handling in __destroy_extent_node()
- 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
- Fix
- Fixed in 6.6.144, 6.12.95, 6.18.38, 6.2, 7.1, and 1 more
- 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 incorrect FI_NO_EXTENT handling in __destroy_extent_node() When __destroy_extent_node() sets the inode flag FI_NO_EXTENT, it does not reset the length of the largest extent to 0 and update the inode folio. Since modifications to the extent tree are disallowed afterward, the cached largest extent may become stale. This can trigger the following error in xfstests generic/388: F2FS-fs (dm-0): sanity_check_extent_cache: inode (ino=1761) extent info [220057, 57, 6] is incorrect, run fsck to fix In the f2fs_drop_inode path, __destroy_extent_node() does not need to guarantee that et->node_cnt is 0, because concurrency with writeback is expected in this path, and writeback may update the extent cache. This patch reverts commit ed78aeebef05 ("f2fs: fix node_cnt race between extent node destroy and writeback"), and remove the unnecessary zero check of et->node_cnt.
Timeline
- CVE published
- Record last updated
Affected versions
- Linux Linux
From 6.6.140 · fixed in 6.6.144; From 6.12.88 · fixed in 6.12.95; From 6.18.30 · fixed in 6.18.38; From 6.1.191 · fixed in 6.2; From 7.0.7 · fixed in 7.1
- Linux Linux
7.1
- KernelLinux
fixed in 6.6.144; From 6.7.0 · fixed in 6.12.95; From 6.13.0 · fixed in 6.18.38; From 6.19.0 · fixed in 7.1.3