CVE-2025-38677

In the Linux kernel, the following vulnerability has been resolved:

f2fs: fix to avoid out-of-boundary access in dnode page

As Jiaming Zhang reported:

<TASK> _dumpstack lib/dumpstack.c:94 [inline] dumpstacklvl+0x1c1/0x2a0 lib/dumpstack.c:120 printaddressdescription mm/kasan/report.c:378 [inline] printreport+0x17e/0x800 mm/kasan/report.c:480 kasanreport+0x147/0x180 mm/kasan/report.c:593 datablkaddr fs/f2fs/f2fs.h:3053 [inline] f2fsdatablkaddr fs/f2fs/f2fs.h:3058 [inline] f2fsgetdnodeofdata+0x1a09/0x1c40 fs/f2fs/node.c:855 f2fsreserveblock+0x53/0x310 fs/f2fs/data.c:1195 preparewritebegin fs/f2fs/data.c:3395 [inline] f2fswritebegin+0xf39/0x2190 fs/f2fs/data.c:3594 genericperformwrite+0x2c7/0x910 mm/filemap.c:4112 f2fsbufferedwriteiter fs/f2fs/file.c:4988 [inline] f2fsfilewriteiter+0x1ec8/0x2410 fs/f2fs/file.c:5216 newsyncwrite fs/readwrite.c:593 [inline] vfswrite+0x546/0xa90 fs/readwrite.c:686 ksyswrite+0x149/0x250 fs/readwrite.c:738 dosyscallx64 arch/x86/entry/syscall64.c:63 [inline] dosyscall64+0xf3/0x3d0 arch/x86/entry/syscall64.c:94 entrySYSCALL64afterhwframe+0x77/0x7f

The root cause is in the corrupted image, there is a dnode has the same node id w/ its inode, so during f2fsgetdnodeofdata(), it tries to access block address in dnode at offset 934, however it parses the dnode as inode node, so that getdnodeaddr() returns 360, then it tries to access page address from 360 + 934 * 4 = 4096 w/ 4 bytes.

To fix this issue, let's add sanity check for node id of all direct nodes during f2fsgetdnodeofdata().