In the Linux kernel, the following vulnerability has been resolved:
f2fs: fix to do sanity check on node footer for non inode dnode
As syzbot reported below:
------------[ cut here ]------------ kernel BUG at fs/f2fs/file.c:1243! Oops: invalid opcode: 0000 [#1] SMP KASAN NOPTI CPU: 0 UID: 0 PID: 5354 Comm: syz.0.0 Not tainted 6.17.0-rc1-syzkaller-00211-g90d970cade8e #0 PREEMPT(full) RIP: 0010:f2fstruncatehole+0x69e/0x6c0 fs/f2fs/file.c:1243 Call Trace: <TASK> f2fspunchhole+0x2db/0x330 fs/f2fs/file.c:1306 f2fsfallocate+0x546/0x990 fs/f2fs/file.c:2018 vfsfallocate+0x666/0x7e0 fs/open.c:342 ksysfallocate fs/open.c:366 [inline] _dosysfallocate fs/open.c:371 [inline] _sesysfallocate fs/open.c:369 [inline] _x64sysfallocate+0xc0/0x110 fs/open.c:369 dosyscallx64 arch/x86/entry/syscall64.c:63 [inline] dosyscall64+0xfa/0x3b0 arch/x86/entry/syscall64.c:94 entrySYSCALL64afterhwframe+0x77/0x7f RIP: 0033:0x7f1e65f8ebe9
w/ a fuzzed image, f2fs may encounter panic due to it detects inconsistent truncation range in direct node in f2fstruncatehole().
The root cause is: a non-inode dnode may has the same footer.ino and footer.nid, so the dnode will be parsed as an inode, then ADDRSPERPAGE() may return wrong blkaddr count which may be 923 typically, by chance, dn.ofsinnode is equal to 923, then count can be calculated to 0 in below statement, later it will trigger panic w/ f2fsbugon(, count == 0 || ...).
count = min(end_offset - dn.ofs_in_node, pg_end - pg_start);
This patch introduces a new nodetype NODETYPENONINODE, then allowing passing the newtype to sanitychecknodefooter in f2fsgetnode_folio() to detect corruption that a non-inode dnode has the same footer.ino and footer.nid.
Scripts to reproduce: mkfs.f2fs -f /dev/vdb mount /dev/vdb /mnt/f2fs touch /mnt/f2fs/foo touch /mnt/f2fs/bar dd if=/dev/zero of=/mnt/f2fs/foo bs=1M count=8 umount /mnt/f2fs inject.f2fs --node --mb inid --nid 4 --idx 0 --val 5 /dev/vdb mount /dev/vdb /mnt/f2fs xfsio /mnt/f2fs/foo -c "fpunch 6984k 4k"
{
"cna_assigner": "Linux",
"osv_generated_from": "https://github.com/CVEProject/cvelistV5/tree/main/cves/2025/40xxx/CVE-2025-40025.json"
}