In the Linux kernel, the following vulnerability has been resolved: f2fs: fix to do sanity check on sbi->totalvalidblockcount syzbot reported a f2fs bug as below: ------------[ cut here ]------------ kernel BUG at fs/f2fs/f2fs.h:2521! RIP: 0010:decvalidblockcount+0x3b2/0x3c0 fs/f2fs/f2fs.h:2521 Call Trace: f2fstruncatedatablocksrange+0xc8c/0x11a0 fs/f2fs/file.c:695 truncatednode+0x417/0x740 fs/f2fs/node.c:973 truncatenodes+0x3ec/0xf50 fs/f2fs/node.c:1014 f2fstruncateinodeblocks+0x8e3/0x1370 fs/f2fs/node.c:1197 f2fsdotruncateblocks+0x840/0x12b0 fs/f2fs/file.c:810 f2fstruncateblocks+0x10d/0x300 fs/f2fs/file.c:838 f2fstruncate+0x417/0x720 fs/f2fs/file.c:888 f2fssetattr+0xc4f/0x12f0 fs/f2fs/file.c:1112 notifychange+0xbca/0xe90 fs/attr.c:552 dotruncate+0x222/0x310 fs/open.c:65 handletruncate fs/namei.c:3466 [inline] doopen fs/namei.c:3849 [inline] pathopenat+0x2e4f/0x35d0 fs/namei.c:4004 dofilpopen+0x284/0x4e0 fs/namei.c:4031 dosysopenat2+0x12b/0x1d0 fs/open.c:1429 dosysopen fs/open.c:1444 [inline] _dosyscreat fs/open.c:1522 [inline] _sesyscreat fs/open.c:1516 [inline] _x64syscreat+0x124/0x170 fs/open.c:1516 dosyscallx64 arch/x86/entry/syscall64.c:63 [inline] dosyscall64+0xf3/0x230 arch/x86/entry/syscall64.c:94 The reason is: in fuzzed image, sbi->totalvalidblock_count is inconsistent w/ mapped blocks indexed by inode, so, we should not trigger panic for such case, instead, let's print log and set fsck flag.