CVE-2024-42297

What it actually does

The flaw allows f2fs_lookup to call f2fs_i_depth_write and mark an inode dirty via f2fs_mark_inode_dirty_sync even when the filesystem is mounted read-only, violating the invariant checked in f2fs_evict_inode and triggering a kernel BUG during generic_shutdown_super on umount.

Why it matters to the business

Systems using the f2fs filesystem on Linux experience unexpected kernel panics during unmount of read-only volumes, leading to service disruption and potential data loss in environments with 2,868 downstream dependents; the flat EPSS and lack of KEV status indicate low immediate exploitation urgency but still require prompt patching.

How an attack unfolds

An attacker with the ability to trigger directory lookups (for example via do_sys_open on a read-only f2fs mount) causes i_current_depth repair to dirty the inode; later unmount via kill_f2fs_super and evict_inodes hits the FI_DIRTY_INODE assertion in f2fs_evict_inode and panics the kernel. Mentions of 2024 zero-day campaigns by espionage actors and Linux kernel resource vulnerabilities provide context but no confirmed active exploitation of this specific issue.

How to fix it

Upgrade the Linux kernel to commit 2d2916516577f2239b3377d9e8d12da5e6ccdfcf or later stable releases that contain the fix; avoid performing directory operations that repair i_current_depth on read-only f2fs mounts until patched.

How to confirm the fix worked

Verify the running kernel contains commit 2d2916516577f2239b3377d9e8d12da5e6ccdfcf, reproduce the original syzbot reproducer on a read-only f2fs mount and confirm no BUG occurs in f2fs_evict_inode during umount, and inspect fs/f2fs/inode.c for the added read-only check before marking the inode dirty.

Typical attack path

1. Mount f2fs filesystem read-only
2. Perform operations that invoke f2fs_lookup and __f2fs_find_entry on directories
3. Trigger f2fs_i_depth_write which calls f2fs_mark_inode_dirty_sync
4. Initiate umount which calls kill_f2fs_super and generic_shutdown_super
5. evict_inodes runs iput leading to f2fs_evict_inode and the BUG_ON assertion

How to detect it

Search kernel logs and crash dumps for the exact BUG message at fs/f2fs/inode.c:933 or the RIP address f2fs_evict_inode+0x1576; examine audit logs for sequences of open, lookup, and umount calls on f2fs mounts that coincide with unexpected panics; review dmesg output around kill_f2fs_super and evict_inodes for read-only mount indicators.

What your security team should do

• Prioritize kernel updates on all systems using f2fs within the next maintenance window given the 786 days since publication and 2,868 downstream dependents
• Add f2fs read-only mount scenarios to regression test suites for filesystem unmount paths
• Monitor for kernel BUG reports at fs/f2fs/inode.c:933 in production logs
• Consider temporary mitigation by avoiding directory depth repairs on read-only f2fs volumes