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->totalvalidblockcount 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.
In the Linux kernel, the following vulnerability has been resolved:
f2fs: avoid infinite loop to flush node pages
xfstests/generic/475 can give EIO all the time which give an infinite loop to flush node page like below. Let's avoid it.
[16418.518551] Call Trace: [16418.518553] ? dmsubmitbio+0x48/0x400 [16418.518574] ? submitbiochecks+0x1ac/0x5a0 [16418.525207] submitbio+0x1a9/0x230 [16418.525210] ? kmemcachealloc+0x29e/0x3c0 [16418.525223] submitbionoacct+0xa8/0x2b0 [16418.525226] submitbio+0x4d/0x130 [16418.525238] submitbio+0x49/0x310 [f2fs] [16418.525339] ? bioaddpage+0x6a/0x90 [16418.525344] f2fssubmitpagebio+0x134/0x1f0 [f2fs] [16418.525365] readnodepage+0x125/0x1b0 [f2fs] [16418.525388] getnodepage.part.0+0x58/0x3f0 [f2fs] [16418.525409] getnodepage+0x2f/0x60 [f2fs] [16418.525431] f2fsgetdnodeofdata+0x423/0x860 [f2fs] [16418.525452] ? asmsysvecapictimerinterrupt+0x12/0x20 [16418.525458] ? modmemcgstate.part.0+0x2a/0x30 [16418.525465] ? modmemcglruvecstate+0x27/0x40 [16418.525467] ? xasetmark+0x57/0x70 [16418.525472] f2fsdowritedatapage+0x10e/0x7b0 [f2fs] [16418.525493] f2fswritesingledatapage+0x555/0x830 [f2fs] [16418.525514] ? sysvecapictimerinterrupt+0x4e/0x90 [16418.525518] ? asmsysvecapictimerinterrupt+0x12/0x20 [16418.525523] f2fswritecachepages+0x303/0x880 [f2fs] [16418.525545] ? blkflushpluglist+0x47/0x100 [16418.525548] f2fswritedatapages+0xfd/0x320 [f2fs] [16418.525569] dowritepages+0xd5/0x210 [16418.525648] filemapfdatawritewbc+0x7d/0xc0 [16418.525655] filemapfdatawrite+0x50/0x70 [16418.525658] f2fssyncdirtyinodes+0xa4/0x230 [f2fs] [16418.525679] f2fswritecheckpoint+0x16d/0x1720 [f2fs] [16418.525699] ? ttwudowakeup+0x1c/0x160 [16418.525709] ? ttwudoactivate+0x6d/0xd0 [16418.525711] ? waitforcommon+0x11d/0x150 [16418.525715] killf2fssuper+0xca/0x100 [f2fs] [16418.525733] deactivatelockedsuper+0x3b/0xb0 [16418.525739] deactivatesuper+0x40/0x50 [16418.525741] cleanupmnt+0x139/0x190 [16418.525747] cleanupmnt+0x12/0x20 [16418.525749] taskworkrun+0x6d/0xa0 [16418.525765] exittousermodeprepare+0x1ad/0x1b0 [16418.525771] syscallexittousermode+0x27/0x50 [16418.525774] dosyscall64+0x48/0xc0 [16418.525776] entrySYSCALL64afterhwframe+0x44/0xae
In the Linux kernel, the following vulnerability has been resolved:
f2fs: fix to avoid racing on fsyncentryslab by multi filesystem instances
As syzbot reported, there is an use-after-free issue during f2fs recovery:
Use-after-free write at 0xffff88823bc16040 (in kfence-#10): kmemcachedestroy+0x1f/0x120 mm/slabcommon.c:486 f2fsrecoverfsyncdata+0x75b0/0x8380 fs/f2fs/recovery.c:869 f2fsfillsuper+0x9393/0xa420 fs/f2fs/super.c:3945 mountbdev+0x26c/0x3a0 fs/super.c:1367 legacygettree+0xea/0x180 fs/fscontext.c:592 vfsgettree+0x86/0x270 fs/super.c:1497 donewmount fs/namespace.c:2905 [inline] pathmount+0x196f/0x2be0 fs/namespace.c:3235 domount fs/namespace.c:3248 [inline] dosysmount fs/namespace.c:3456 [inline] sesysmount+0x2f9/0x3b0 fs/namespace.c:3433 dosyscall64+0x3f/0xb0 arch/x86/entry/common.c:47 entrySYSCALL64afterhwframe+0x44/0xae
The root cause is multi f2fs filesystem instances can race on accessing global fsyncentryslab pointer, result in use-after-free issue of slab cache, fixes to init/destroy this slab cache only once during module init/destroy procedure to avoid this issue.