CVE-2024-40969

What it actually does

Race condition in f2fs causes deadlock during shutdown when bdev_thaw encounters sb_rdonly after f2fs_stop_checkpoint sets the filesystem read-only, blocking discard thread and kthread_stop.

Why it matters to the business

Filesystem operations on affected Linux systems can hang indefinitely, leading to service outages, data unavailability, and forced reboots with potential data loss on f2fs volumes.

How an attack unfolds

An attacker with local access triggers f2fs_ioc_shutdown(F2FS_GOING_DOWN_FULLSYNC) while the discard thread is active; the resulting freeze/thaw sequence deadlocks the kernel without requiring remote code execution.

How to fix it

Upgrade the Linux kernel to commit 1036d3ea7a32cb7cee00885c73a1f2ba7fbc499a or later stable releases containing the fix; rebuild and reboot with the patched kernel.

How to confirm the fix worked

Confirm kernel version includes commit 1036d3ea7a32cb7cee00885c73a1f2ba7fbc499a; reproduce shutdown sequence in test environment and verify no deadlock occurs; review f2fs source for absence of set RO path during shutdown.

Typical attack path

1. Obtain local shell or process execution on target system
2. Mount or access an f2fs filesystem
3. Issue F2FS_GOING_DOWN_FULLSYNC ioctl via f2fs_ioc_shutdown
4. Trigger concurrent discard thread activity
5. Observe kernel deadlock on thaw_super returning -EINVAL

How to detect it

Search kernel logs for f2fs_handle_critical_error combined with thaw_super_locked failures and kthread_stop waits; monitor for prolonged sb_start_write blocks on f2fs filesystems.

What your security team should do

• Prioritize kernel upgrade on all systems using f2fs within 30 days given publication age
• Audit f2fs usage in production workloads and schedule maintenance windows
• Enable kernel panic on oops and monitor for f2fs-related hangs
• Test patched kernels in staging before broad deployment