In the Linux kernel, the following vulnerability has been resolved:
f2fs: fix fsck inconsistency caused by FGGC of node block
During FGGC node block migration, fsck may incorrectly treat the migrated node block as fsync-written data.
The reproduction scenario: root@vm:/mnt/f2fs# seq 1 2048 | xargs -n 1 ./testsync // write inline inode and sync root@vm:/mnt/f2fs# rm -f 1 root@vm:/mnt/f2fs# sync root@vm:/mnt/f2fs# f2fsio gcrange // move data block in sync mode and not write CP SPO, "fsck --dry-run" find inode has already checkpointed but still with DENTBITSHIFT set
The root cause is that GC does not clear the dentry mark and fsync mark during node block migration, leading fsck to misinterpret them as user-issued fsync writes.
In BGGC mode, node block migration is handled by f2fssyncnodepages(), which guarantees the dentry and fsync marks are cleared before writing.
This patch move the set/clear of the fsync|dentry marks into writenodefolio to make the logic clearer, and ensures the fsync|dentry mark is cleared in FGGC.
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".