CVE-2024-47689

What it actually does

Race condition in f2fs_handle_critical_error allows setting SB_RDONLY flag without sb->s_umount semaphore protection, leading to skipped sb_freeze_unlock during thaw_super and subsequent rcu_sync_dtor failure in destroy_super_work.

Why it matters to the business

Kernel warnings, potential hangs or crashes on f2fs filesystems when critical errors occur concurrently with freeze/thaw operations, increasing operational risk in Linux environments using this filesystem.

How an attack unfolds

An attacker triggers a critical error condition in f2fs (via crafted I/O or filesystem stress), races the internal SB_RDONLY assignment against freeze_super and thaw_super paths, causing improper freeze state and RCU synchronization failure during superblock teardown.

How to fix it

Update Linux kernel to commit 2dde18cd1d8fac735875f2e4987f11817cc0bc2c or later equivalent; rebuild and reboot affected systems; align f2fs error handling with ext4 by removing direct SB_RDONLY assignment.

How to confirm the fix worked

Verify kernel git commit or package version includes 2dde18cd1d8fac735875f2e4987f11817cc0bc2c; reproduce f2fs critical error under freeze/thaw load and confirm absence of rcu_sync_dtor warnings in dmesg.

Typical attack path

1. Trigger f2fs critical error path with errors=remount-ro mount option
2. Concurrently invoke freeze_super and thaw_super operations
3. Race window allows SB_RDONLY set without proper locking
4. thaw_super_locked skips sb_freeze_unlock due to sb_rdonly check
5. deactivate_locked_super proceeds leading to rcu_sync_dtor warning and workqueue crash

How to detect it

Search kernel logs and dmesg for rcu_sync_dtor warnings combined with f2fs_handle_critical_error calls; inspect workqueue traces involving destroy_super_work; correlate with f2fs mount options and critical error events.

• rcu_sync_dtor+0xcd/0x180
• f2fs_handle_critical_error
• destroy_super_work
• WARNING: CPU:.*PID:.*at kernel/rcu/sync.c:177
• sb->s_flags |= SB_RDONLY

What your security team should do

• Prioritize kernel upgrade to fixed version across all Linux deployments using f2fs
• Monitor kernel logs for rcu_sync_dtor and f2fs_handle_critical_error entries
• Consider temporary mitigation by avoiding errors=remount-ro on f2fs mounts if upgrade delayed
• Test filesystem error paths in staging environments before production rollout