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.
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.