CVE-2024-53218

In the Linux kernel, the following vulnerability has been resolved:

f2fs: fix race in concurrent f2fs_stop_gc_thread

In my test case, concurrent calls to f2fs shutdown report the following stack trace:

Oops: general protection fault, probably for non-canonical address 0xc6cfff63bb5513fc: 0000 [#1] PREEMPT SMP PTI CPU: 0 UID: 0 PID: 678 Comm: f2fs_rep_shutdo Not tainted 6.12.0-rc5-next-20241029-g6fb2fa9805c5-dirty #85 Call Trace: ? show_regs+0x8b/0xa0 ? __die_body+0x26/0xa0 ? die_addr+0x54/0x90 ? exc_general_protection+0x24b/0x5c0 ? asm_exc_general_protection+0x26/0x30 ? kthread_stop+0x46/0x390 f2fs_stop_gc_thread+0x6c/0x110 f2fs_do_shutdown+0x309/0x3a0 f2fs_ioc_shutdown+0x150/0x1c0 __f2fs_ioctl+0xffd/0x2ac0 f2fs_ioctl+0x76/0xe0 vfs_ioctl+0x23/0x60 __x64_sys_ioctl+0xce/0xf0 x64_sys_call+0x2b1b/0x4540 do_syscall_64+0xa7/0x240 entry_SYSCALL_64_after_hwframe+0x76/0x7e

The root cause is a race condition in f2fs_stop_gc_thread() called from different f2fs shutdown paths:

[CPU0] [CPU1]

f2fs_stop_gc_thread f2fs_stop_gc_thread gc_th = sbi->gc_thread gc_th = sbi->gc_thread kfree(gc_th) sbi->gc_thread = NULL < gc_th != NULL > kthread_stop(gc_th->f2fs_gc_task) //UAF

The commit c7f114d864ac (f2fs: fix to avoid use-after-free in f2fs_stop_gc_thread()) attempted to fix this issue by using a read semaphore to prevent races between shutdown and remount threads, but it fails to prevent all race conditions.

Fix it by converting to write lock of s_umount in f2fs_do_shutdown().

Weakness

Referencing memory after it has been freed can cause a program to crash, use unexpected values, or execute code.

Affected Software

Extended Description

The use of previously-freed memory can have any number of adverse consequences, ranging from the corruption of valid data to the execution of arbitrary code, depending on the instantiation and timing of the flaw. The simplest way data corruption may occur involves the system’s reuse of the freed memory. Use-after-free errors have two common and sometimes overlapping causes:

In this scenario, the memory in question is allocated to another pointer validly at some point after it has been freed. The original pointer to the freed memory is used again and points to somewhere within the new allocation. As the data is changed, it corrupts the validly used memory; this induces undefined behavior in the process. If the newly allocated data happens to hold a class, in C++ for example, various function pointers may be scattered within the heap data. If one of these function pointers is overwritten with an address to valid shellcode, execution of arbitrary code can be achieved.

Potential Mitigations

References

• https://git.kernel.org/stable/c/60457ed6c67625c87861f96912b4179dc2293896
• https://git.kernel.org/stable/c/794fa8792d4eacac191f1cbcc2e81b7369e4662a
• https://git.kernel.org/stable/c/7b0033dbc48340a1c1c3f12448ba17d6587ca092
• https://git.kernel.org/stable/c/c631207897a9b3d41167ceca58e07f8f94720e42