In the Linux kernel, the following vulnerability has been resolved:
f2fs: fix to do sanity check on direct node in truncatednode()
syzbot reports below bug:
BUG: KASAN: slab-use-after-free in f2fstruncatedatablocksrange+0x122a/0x14c0 fs/f2fs/file.c:574 Read of size 4 at addr ffff88802a25c000 by task syz-executor148/5000
CPU: 1 PID: 5000 Comm: syz-executor148 Not tainted 6.4.0-rc7-syzkaller-00041-ge660abd551f1 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 05/27/2023 Call Trace: <TASK> dumpstack lib/dumpstack.c:88 [inline] dumpstacklvl+0xd9/0x150 lib/dumpstack.c:106 printaddressdescription.constprop.0+0x2c/0x3c0 mm/kasan/report.c:351 printreport mm/kasan/report.c:462 [inline] kasanreport+0x11c/0x130 mm/kasan/report.c:572 f2fstruncatedatablocksrange+0x122a/0x14c0 fs/f2fs/file.c:574 truncatednode+0x229/0x2e0 fs/f2fs/node.c:944 f2fstruncateinodeblocks+0x64b/0xde0 fs/f2fs/node.c:1154 f2fsdotruncateblocks+0x4ac/0xf30 fs/f2fs/file.c:721 f2fstruncateblocks+0x7b/0x300 fs/f2fs/file.c:749 f2fstruncate.part.0+0x4a5/0x630 fs/f2fs/file.c:799 f2fstruncate include/linux/fs.h:825 [inline] f2fssetattr+0x1738/0x2090 fs/f2fs/file.c:1006 notifychange+0xb2c/0x1180 fs/attr.c:483 dotruncate+0x143/0x200 fs/open.c:66 handletruncate fs/namei.c:3295 [inline] doopen fs/namei.c:3640 [inline] pathopenat+0x2083/0x2750 fs/namei.c:3791 dofilpopen+0x1ba/0x410 fs/namei.c:3818 dosysopenat2+0x16d/0x4c0 fs/open.c:1356 dosysopen fs/open.c:1372 [inline] dosyscreat fs/open.c:1448 [inline] sesyscreat fs/open.c:1442 [inline] x64syscreat+0xcd/0x120 fs/open.c:1442 dosyscallx64 arch/x86/entry/common.c:50 [inline] dosyscall64+0x39/0xb0 arch/x86/entry/common.c:80 entrySYSCALL64afterhwframe+0x63/0xcd
The root cause is, inodeA references inodeB via inodeB's ino, once inodeA is truncated, it calls truncatednode() to truncate data blocks in inodeB's node page, it traverse mapping data from node->i.iaddr[0] to node->i.iaddr[ADDRSPERBLOCK() - 1], result in out-of-boundary access.
This patch fixes to add sanity check on dnode page in truncatednode(), so that, it can help to avoid triggering such issue, and once it encounters such issue, it will record newly introduced ERRORINVALIDNODEREFERENCE error into superblock, later fsck can detect such issue and try repairing.
Also, it removes f2fstruncatedatablocks() for cleanup due to the function has only one caller, and uses f2fstruncatedatablocksrange() instead.
In the Linux kernel, the following vulnerability has been resolved:
Revert "f2fs: fix to do sanity check on extent cache correctly"
syzbot reports a f2fs bug as below:
UBSAN: array-index-out-of-bounds in fs/f2fs/f2fs.h:3275:19 index 1409 is out of range for type 'le32[923]' (aka 'unsigned int[923]') Call Trace: dumpstack lib/dumpstack.c:88 [inline] dumpstacklvl+0x1e7/0x2d0 lib/dumpstack.c:106 ubsanepilogue lib/ubsan.c:217 [inline] ubsanhandleoutofbounds+0x11c/0x150 lib/ubsan.c:348 inlinedataaddr fs/f2fs/f2fs.h:3275 [inline] recoverinlinestatus fs/f2fs/inode.c:113 [inline] doreadinode fs/f2fs/inode.c:480 [inline] f2fsiget+0x4730/0x48b0 fs/f2fs/inode.c:604 f2fsfillsuper+0x640e/0x80c0 fs/f2fs/super.c:4601 mountbdev+0x276/0x3b0 fs/super.c:1391 legacygettree+0xef/0x190 fs/fscontext.c:611 vfsgettree+0x8c/0x270 fs/super.c:1519 donewmount+0x28f/0xae0 fs/namespace.c:3335 domount fs/namespace.c:3675 [inline] dosysmount fs/namespace.c:3884 [inline] sesysmount+0x2d9/0x3c0 fs/namespace.c:3861 dosyscallx64 arch/x86/entry/common.c:50 [inline] dosyscall64+0x41/0xc0 arch/x86/entry/common.c:80 entrySYSCALL64afterhwframe+0x63/0xcd
The issue was bisected to:
commit d48a7b3a72f121655d95b5157c32c7d555e44c05 Author: Chao Yu <chao@kernel.org> Date: Mon Jan 9 03:49:20 2023 +0000
f2fs: fix to do sanity check on extent cache correctly
The root cause is we applied both v1 and v2 of the patch, v2 is the right fix, so it needs to revert v1 in order to fix reported issue.
v1: commit d48a7b3a72f1 ("f2fs: fix to do sanity check on extent cache correctly") https://lore.kernel.org/lkml/20230109034920.492914-1-chao@kernel.org/
v2: commit 269d11948100 ("f2fs: fix to do sanity check on extent cache correctly") https://lore.kernel.org/lkml/20230207134808.1827869-1-chao@kernel.org/