CVE-2024-42296

What it actually does

Incorrect return value from f2fs_convert_inline_inode on a read-only device (zero instead of EROFS) allows dirty inline inode pages to proceed to writeback, triggering a kernel panic via the f2fs write path.

Why it matters to the business

Systems using the f2fs filesystem on read-only mounts can experience unexpected kernel panics and crashes, leading to downtime and data inconsistency risks; with 27,427 downstream dependents this affects a wide range of Linux distributions and embedded devices.

How an attack unfolds

An attacker triggers f2fs_convert_inline_inode on a read-only f2fs volume (for example via a write syscall or sync operation on an inline inode) so the function returns success instead of EROFS; subsequent dirty-page writeback then follows the call stack into f2fs_write_single_data_page and panics the kernel.

How to fix it

Upgrade the Linux kernel to a version containing commit 70f5ef5f33c333cfb286116fa3af74ac9bc84f1b or apply the equivalent stable backport; rebuild and reboot affected systems.

How to confirm the fix worked

Confirm the running kernel contains the fix commit or test that f2fs_convert_inline_inode now returns EROFS on a read-only device; monitor for absence of the associated panic stack trace after the update.

Typical attack path

1. Mount an f2fs filesystem as read-only
2. Create or access an inline inode
3. Perform a write or sync operation that calls f2fs_convert_inline_inode
4. Function returns zero instead of EROFS
5. Kernel attempts writeback of the dirty page and panics

How to detect it

Search kernel logs and crash dumps for the f2fs writeback panic stack trace beginning with f2fs_write_single_data_page and containing calls through f2fs_write_data_pages, f2fs_do_sync_file, and vfs_write; correlate with f2fs mount options indicating read-only.

• f2fs_write_single_data_page+0xbb6/0x1e90 fs/f2fs/data.c:2888
• f2fs_write_cache_pages fs/f2fs/data.c:3187
• __f2fs_write_data_pages fs/f2fs/data.c:3342
• f2fs_write_data_pages+0x1efe/0x3a90 fs/f2fs/data.c:3369
• f2fs_do_sync_file+0x68a/0x1ae0 fs/f2fs/file.c:276
• f2fs_file_write_iter+0x7bd/0x24e0 fs/f2fs/file.c:4977

What your security team should do

• Apply the kernel patch containing commit 70f5ef5f33c333cfb286116fa3af74ac9bc84f1b as soon as possible on all f2fs-using systems
• Prioritize systems that mount f2fs volumes read-only or in embedded/edge deployments given the high downstream prevalence
• Add monitoring for f2fs writeback panic signatures until patches are deployed