CVE-2024-56692
HighCVSS 7.8Exploitation Probability (EPSS)
Low risk12th percentile - higher than 12% of all known CVEs
Summary
In the Linux kernel, the f2fs filesystem lacked a sanity check on the node block address (blkaddr) in truncate_node(). On a crafted filesystem image, a corrupted NAT entry can cause a kernel panic during block invalidation.
Risk Assessment
A crafted f2fs image can trigger a kernel panic (denial of service) when mounted, potentially disrupting system availability.
Recommendation
Update the Linux kernel to a version containing the f2fs fix (blkaddr sanity check in truncate_node). Avoid mounting untrusted f2fs images.
Other vulnerabilities in Linux kernel (f2fs)
See all- CVE-2026-93235Low risk· EPSS 10%
A flaw was found in the Linux kernel F2FS filesystem where extending a file size across an unaligned EOF boundary did not zero out post-EOF data in the partial page. As a result, stale disk data beyond the previous EOF could be exposed after remounting or crash recovery.
- CVE-2026-89830Low risk· EPSS 10%
In the Linux kernel, __allocate_data_block() in the f2fs filesystem increments the valid block count via inc_valid_block_count() when allocating a new data block, but if the subsequent f2fs_allocate_data_block() fails, the function returns the error without rolling back that increment. This causes a permanent valid block count leak.
- CVE-2026-89829High
In the Linux kernel, f2fs_sanity_check_node_footer() is not passed the correct folio->index value, causing it to check the same nid incorrectly. This can lead to improper node consistency verification in the f2fs filesystem.
Original NVD description (English source)
In the Linux kernel, the following vulnerability has been resolved: f2fs: fix to do sanity check on node blkaddr in truncate_node() syzbot reports a f2fs bug as below: ------------[ cut here ]------------ kernel BUG at fs/f2fs/segment.c:2534! RIP: 0010:f2fs_invalidate_blocks+0x35f/0x370 fs/f2fs/segment.c:2534 Call Trace: truncate_node+0x1ae/0x8c0 fs/f2fs/node.c:909 f2fs_remove_inode_page+0x5c2/0x870 fs/f2fs/node.c:1288 f2fs_evict_inode+0x879/0x15c0 fs/f2fs/inode.c:856 evict+0x4e8/0x9b0 fs/inode.c:723 f2fs_handle_failed_inode+0x271/0x2e0 fs/f2fs/inode.c:986 f2fs_create+0x357/0x530 fs/f2fs/namei.c:394 lookup_open fs/namei.c:3595 [inline] open_last_lookups fs/namei.c:3694 [inline] path_openat+0x1c03/0x3590 fs/namei.c:3930 do_filp_open+0x235/0x490 fs/namei.c:3960 do_sys_openat2+0x13e/0x1d0 fs/open.c:1415 do_sys_open fs/open.c:1430 [inline] __do_sys_openat fs/open.c:1446 [inline] __se_sys_openat fs/open.c:1441 [inline] __x64_sys_openat+0x247/0x2a0 fs/open.c:1441 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0010:f2fs_invalidate_blocks+0x35f/0x370 fs/f2fs/segment.c:2534 The root cause is: on a fuzzed image, blkaddr in nat entry may be corrupted, then it will cause system panic when using it in f2fs_invalidate_blocks(), to avoid this, let's add sanity check on nat blkaddr in truncate_node().
Vulnerability data from NVD (NIST) · CISA KEV · EPSS