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/

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:

f2fs: avoid reading already updated pages during GC

We found the following issue during fuzz testing:

page: refcount:3 mapcount:0 mapping:00000000b6e89c65 index:0x18b2dc pfn:0x161ba9 memcg:f8ffff800e269c00 aops:f2fsmetaaops ino:2 flags: 0x52880000000080a9(locked|waiters|uptodate|lru|private|zone=1|kasantag=0x4a) raw: 52880000000080a9 fffffffec6e17588 fffffffec0ccc088 a7ffff8067063618 raw: 000000000018b2dc 0000000000000009 00000003ffffffff f8ffff800e269c00 page dumped because: VMBUGONFOLIO(foliotestuptodate(folio)) pageowner tracks the page as allocated postallochook+0x58c/0x5ec prepnewpage+0x34/0x284 getpagefromfreelist+0x2dcc/0x2e8c allocpagesnoprof+0x280/0x76c folioallocnoprof+0x18/0xac filemapgetfolio+0x6bc/0xdc4 pagecachegetpage+0x3c/0x104 dogarbagecollect+0x5c78/0x77a4 f2fsgc+0xd74/0x25f0 gcthreadfunc+0xb28/0x2930 kthread+0x464/0x5d8 retfromfork+0x10/0x20 ------------[ cut here ]------------ kernel BUG at mm/filemap.c:1563! folioendread+0x140/0x168 f2fsfinishreadbio+0x5c4/0xb80 f2fsreadendio+0x64c/0x708 bioendio+0x85c/0x8c0 blkupdaterequest+0x690/0x127c scsiendrequest+0x9c/0xb8c scsiiocompletion+0xf0/0x250 scsifinishcommand+0x430/0x45c scsicomplete+0x178/0x6d4 blkmqcompleterequest+0xcc/0x104 scsidoneinternal+0x214/0x454 scsidone+0x24/0x34

which is similar to the problem reported by syzbot: https://syzkaller.appspot.com/bug?extid=3686758660f980b402dc

This case is consistent with the description in commit 9bf1a3f ("f2fs: avoid GC causing encrypted file corrupted"): Page 1 is moved from blkaddr A to blkaddr B by movedatablock, and after being written it is marked as uptodate. Then, Page 1 is moved from blkaddr B to blkaddr C, VMBUGONFOLIO was triggered in the endio initiated by radatablock.

There is no need to read Page 1 again from blkaddr B, since it has already been updated. Therefore, avoid initiating I/O in this case.

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

f2fs: fix data loss caused by incorrect use of natentry flag

Data loss can occur when fsync is performed on a newly created file (before any checkpoint has been written) concurrently with a checkpoint operation. The scenario is as follows:

create & write & fsync 'file A' write checkpoint - f2fsdosyncfile // inline inode - f2fswriteinode // inode folio is dirty - f2fswritecheckpoint - f2fsflushmergedwrites - f2fssyncnodepages - f2fsflushnatentries - f2fsfsyncnodepages // no dirty node - f2fsneedinodeblockupdate // return false SPO and lost 'file A'

f2fsflushnatentries() sets the ISCHECKPOINTED and HASLASTFSYNC flags for the natentry, but this does not mean that the checkpoint has actually completed successfully. However, f2fsneedinodeblockupdate() checks these flags and incorrectly assumes that the checkpoint has finished.

The root cause is that the semantics of ISCHECKPOINTED and HASLASTFSYNC are only guaranteed after the checkpoint write fully completes.

This patch modifies f2fsneedinodeblockupdate() to acquire the sbi->nodewrite lock before reading the natentry flags, ensuring that once ISCHECKPOINTED and HASLASTFSYNC are observed to be set, the checkpoint operation has already completed.

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

f2fs: fix to avoid NULL pointer dereference in f2fscheckquotaconsistency()

syzbot reported a f2fs bug as below:

Oops: gen[ 107.736417][ T5848] Oops: general protection fault, probably for non-canonical address 0xdffffc0000000000: 0000 [#1] SMP KASAN PTI KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007] CPU: 1 UID: 0 PID: 5848 Comm: syz-executor263 Tainted: G W 6.17.0-rc1-syzkaller-00014-g0e39a731820a #0 PREEMPT{RT,(full)} RIP: 0010:strcmp+0x3c/0xc0 lib/string.c:284 Call Trace: <TASK> f2fscheckquotaconsistency fs/f2fs/super.c:1188 [inline] f2fscheckoptconsistency+0x1378/0x2c10 fs/f2fs/super.c:1436 f2fsremount fs/f2fs/super.c:2653 [inline] f2fsreconfigure+0x482/0x1770 fs/f2fs/super.c:5297 reconfiguresuper+0x224/0x890 fs/super.c:1077 doremount fs/namespace.c:3314 [inline] pathmount+0xd18/0xfe0 fs/namespace.c:4112 domount fs/namespace.c:4133 [inline] dosysmount fs/namespace.c:4344 [inline] sesysmount+0x317/0x410 fs/namespace.c:4321 dosyscallx64 arch/x86/entry/syscall64.c:63 [inline] dosyscall64+0xfa/0x3b0 arch/x86/entry/syscall64.c:94 entrySYSCALL64afterhwframe+0x77/0x7f

The direct reason is f2fscheckquotaconsistency() may suffer null-ptr-deref issue in strcmp().

The bug can be reproduced w/ below scripts: mkfs.f2fs -f /dev/vdb mount -t f2fs -o usrquota /dev/vdb /mnt/f2fs quotacheck -uc /mnt/f2fs/ umount /mnt/f2fs mount -t f2fs -o usrjquota=aquota.user,jqfmt=vfsold /dev/vdb /mnt/f2fs mount -t f2fs -o remount,usrjquota=,jqfmt=vfsold /dev/vdb /mnt/f2fs umount /mnt/f2fs

So, before oldqname and newqname comparison, we need to check whether they are all valid pointers, fix it.

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

f2fs: fix to invalidate dcc->f2fsissuediscard in error path

Syzbot reports a NULL pointer dereference issue as below:

refcountadd include/linux/refcount.h:193 [inline] refcountinc include/linux/refcount.h:250 [inline] refcountinc include/linux/refcount.h:267 [inline] gettaskstruct include/linux/sched/task.h:110 [inline] kthreadstop+0x34/0x1c0 kernel/kthread.c:703 f2fsstopdiscardthread+0x3c/0x5c fs/f2fs/segment.c:1638 killf2fssuper+0x5c/0x194 fs/f2fs/super.c:4522 deactivatelockedsuper+0x70/0xe8 fs/super.c:332 deactivatesuper+0xd0/0xd4 fs/super.c:363 cleanupmnt+0x1f8/0x234 fs/namespace.c:1186 cleanupmnt+0x20/0x30 fs/namespace.c:1193 taskworkrun+0xc4/0x14c kernel/taskwork.c:177 exittaskwork include/linux/taskwork.h:38 [inline] doexit+0x26c/0xbe0 kernel/exit.c:795 dogroupexit+0x60/0xe8 kernel/exit.c:925 dosysexitgroup kernel/exit.c:936 [inline] sesysexitgroup kernel/exit.c:934 [inline] wakeupparent+0x0/0x40 kernel/exit.c:934 invokesyscall arch/arm64/kernel/syscall.c:38 [inline] invokesyscall arch/arm64/kernel/syscall.c:52 [inline] el0svccommon+0x138/0x220 arch/arm64/kernel/syscall.c:142 doel0svc+0x48/0x164 arch/arm64/kernel/syscall.c:206 el0svc+0x58/0x150 arch/arm64/kernel/entry-common.c:636 el0t64synchandler+0x84/0xf0 arch/arm64/kernel/entry-common.c:654 el0t64sync+0x18c/0x190 arch/arm64/kernel/entry.S:581

The root cause of this issue is in error path of f2fsstartdiscardthread(), it missed to invalidate dcc->f2fsissuediscard, later kthreadstop() may access invalid pointer.