CVE-2024-53218

What it actually does

Race condition in f2fs_stop_gc_thread allows concurrent callers to free the gc_thread structure while another thread still holds a reference, resulting in use-after-free during kthread_stop.

Why it matters to the business

Systems using the f2fs filesystem can experience kernel crashes or potential code execution during shutdown operations, leading to data corruption risk, service outages, and the need for urgent kernel updates across Linux deployments.

How an attack unfolds

An attacker with local access triggers multiple concurrent f2fs shutdown ioctls from separate threads or processes; the race lets one path free the gc_thread while the other dereferences it, causing a general protection fault that may be leveraged for privilege escalation in unpatched kernels.

How to fix it

Upgrade the Linux kernel to a version containing commit 794fa8792d4eacac191f1cbcc2e81b7369e4662a, which replaces the insufficient read semaphore with a write lock on s_umount inside f2fs_do_shutdown.

How to confirm the fix worked

Verify the running kernel contains commit 794fa8792d4eacac191f1cbcc2e81b7369e4662a or later; confirm absence of the race by reviewing the updated f2fs_do_shutdown and f2fs_stop_gc_thread code paths.

Typical attack path

1. Obtain local user access on a system mounting f2fs filesystems
2. Issue concurrent F2FS_IOC_SHUTDOWN ioctls from multiple processes
3. Trigger the race between f2fs_do_shutdown paths calling f2fs_stop_gc_thread
4. Cause use-after-free in kthread_stop on the freed gc_thread structure
5. Exploit the resulting memory corruption for kernel code execution

How to detect it

Search kernel logs for oops or general protection fault traces containing f2fs_stop_gc_thread, f2fs_do_shutdown, and kthread_stop; inspect for concurrent f2fs shutdown ioctl calls preceding the crash.

• f2fs_stop_gc_thread+0x6c/0x110
• f2fs_do_shutdown+0x309/0x3a0
• general protection fault, probably for non-canonical address
• kthread_stop(gc_th->f2fs_gc_task)

What your security team should do

• Apply the kernel patch containing 794fa8792d4eacac191f1cbcc2e81b7369e4662a immediately on all f2fs-using systems
• Prioritize updates for production servers and containers using f2fs
• Monitor for kernel oops reports involving f2fs_stop_gc_thread until patches are deployed
• Restrict unprivileged ioctl access to f2fs devices where feasible