CVE-2024-47691

What it actually does

Use-after-free in f2fs_stop_gc_thread caused by race between f2fs_remount (which frees gc_th) and f2fs_do_shutdown (which calls kthread_stop on the freed gc_th pointer) without proper sb->s_umount serialization on the ioctl path.

Why it matters to the business

Local attackers on f2fs filesystems can trigger kernel crashes or memory corruption, leading to denial of service or potential privilege escalation on affected Linux systems; low urgency as not observed in ransomware or KEV campaigns and EPSS remains minimal with no trend increase.

How an attack unfolds

A local attacker with write access to an f2fs mount issues f2fs_ioc_shutdown while a concurrent remount is freeing the gc_thread structure; the missing semaphore grab allows kthread_stop to dereference the now-freed gc_th pointer, resulting in use-after-free during refcount operations.

How to fix it

Upgrade to a kernel containing the fix that ensures sb->s_umount is held for the f2fs_ioc_shutdown path; apply vendor-supplied f2fs patches addressing the gc_th race.

How to confirm the fix worked

Confirm presence of semaphore acquisition around f2fs_do_shutdown in f2fs/file.c and f2fs_stop_gc_thread in gc.c; test concurrent remount + shutdown sequences under KASAN; verify no crash reports reference f2fs_stop_gc_thread after update.

Typical attack path

1. Obtain local shell on system with f2fs filesystem
2. Trigger f2fs_ioc_shutdown ioctl concurrently with remount operation
3. Race frees gc_th while kthread_stop executes on stale pointer
4. Kernel hits KASAN-detected use-after-free in refcount_inc / get_task_struct

How to detect it

Search kernel logs and KASAN reports for stacks containing f2fs_stop_gc_thread, f2fs_do_shutdown, and kthread_stop; look for concurrent remount and shutdown ioctl sequences in audit or syscall logs.

• f2fs_stop_gc_thread+0x65/0xb0
• f2fs_do_shutdown+0x192/0x540
• kthread_stop+0xca/0x630
• kasan_report.*refcount_inc

What your security team should do

• Prioritize kernel updates for f2fs users within normal patch cycles
• Restrict unprivileged use of f2fs ioctls via LSM or capabilities where possible
• Monitor for kernel oops involving f2fs_gc_thread and kthread_stop