CVE-2021-47335

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> f2fs: fix to avoid racing on fsync_entry_slab by multi filesystem instances<br /> <br /> As syzbot reported, there is an use-after-free issue during f2fs recovery:<br /> <br /> Use-after-free write at 0xffff88823bc16040 (in kfence-#10):<br /> kmem_cache_destroy+0x1f/0x120 mm/slab_common.c:486<br /> f2fs_recover_fsync_data+0x75b0/0x8380 fs/f2fs/recovery.c:869<br /> f2fs_fill_super+0x9393/0xa420 fs/f2fs/super.c:3945<br /> mount_bdev+0x26c/0x3a0 fs/super.c:1367<br /> legacy_get_tree+0xea/0x180 fs/fs_context.c:592<br /> vfs_get_tree+0x86/0x270 fs/super.c:1497<br /> do_new_mount fs/namespace.c:2905 [inline]<br /> path_mount+0x196f/0x2be0 fs/namespace.c:3235<br /> do_mount fs/namespace.c:3248 [inline]<br /> __do_sys_mount fs/namespace.c:3456 [inline]<br /> __se_sys_mount+0x2f9/0x3b0 fs/namespace.c:3433<br /> do_syscall_64+0x3f/0xb0 arch/x86/entry/common.c:47<br /> entry_SYSCALL_64_after_hwframe+0x44/0xae<br /> <br /> The root cause is multi f2fs filesystem instances can race on accessing<br /> global fsync_entry_slab pointer, result in use-after-free issue of slab<br /> cache, fixes to init/destroy this slab cache only once during module<br /> init/destroy procedure to avoid this issue.