f2fs: fix fsck inconsistency caused by FGGC of node block
In the Linux kernel, the following vulnerability has been resolved:
f2fs: fix to avoid memory leak in f2fsrename()
syzbot reported a f2fs bug as below:
BUG: memory leak unreferenced object 0xffff888127f70830 (size 16): comm "syz.0.23", pid 6144, jiffies 4294943712 hex dump (first 16 bytes): 3c af 57 72 5b e6 8f ad 6e 8e fd 33 42 39 03 ff <.Wr[...n..3B9.. backtrace (crc 925f8a80): kmemleakallocrecursive include/linux/kmemleak.h:44 [inline] slabpostallochook mm/slub.c:4520 [inline] slaballocnode mm/slub.c:4844 [inline] dokmallocnode mm/slub.c:5237 [inline] kmallocnoprof+0x3bd/0x560 mm/slub.c:5250 kmallocnoprof include/linux/slab.h:954 [inline] fscryptsetupfilename+0x15e/0x3b0 fs/crypto/fname.c:364 f2fssetupfilename+0x52/0xb0 fs/f2fs/dir.c:143 f2fsrename+0x159/0xca0 fs/f2fs/namei.c:961 f2fsrename2+0xd5/0xf20 fs/f2fs/namei.c:1308 vfsrename+0x7ff/0x1250 fs/namei.c:6026 filenamerenameat2+0x4f4/0x660 fs/namei.c:6144 dosysrenameat2 fs/namei.c:6173 [inline] sesysrenameat2 fs/namei.c:6168 [inline] x64sysrenameat2+0x59/0x80 fs/namei.c:6168 dosyscallx64 arch/x86/entry/syscall64.c:63 [inline] dosyscall64+0xe2/0xf80 arch/x86/entry/syscall64.c:94 entrySYSCALL64afterhwframe+0x77/0x7f
The root cause is in commit 40b2d55e0452 ("f2fs: fix to create selinux label during whiteout initialization"), we added a call to f2fssetupfilename() without a matching call to f2fsfreefilename(), fix it.
In the Linux kernel, the following vulnerability has been resolved:
f2fs: fix to avoid migrating empty section
It reports a bug from device w/ zufs:
F2FS-fs (dm-64): Inconsistent segment (173822) type [1, 0] in SSA and SIT F2FS-fs (dm-64): Stopped filesystem due to reason: 4
Thread A Thread B - f2fsexpandinodedata - f2fsallocatepinningsection - f2fsgcrange - dogarbagecollect w/ segno #x - writepage - f2fsallocatedatablock - newcurseg - allocate segno #x
The root cause is: fallocate on pinning file may race w/ block allocation as above, result in dogarbagecollect() from fallocate() may migrate segment which is just allocated by a log, the log will update segment type in its in-memory structure, however GC will get segment type from on-disk SSA block, once segment type changes by log, we can detect such inconsistency, then shutdown filesystem.
In this case, on-disk SSA shows type of segno #173822 is 1 (SUMTYPENODE), however segno #173822 was just allocated as data type segment, so in-memory SIT shows type of segno #173822 is 0 (SUMTYPEDATA).
Change as below to fix this issue: - check whether current section is empty before gc - add sanity checks on dogarbagecollect() to avoid any race case, result in migrating segment used by log. - btw, it fixes misc issue in printed logs: "SSA and SIT" -> "SIT and SSA".