CVE-2024-56586

What it actually does

Triggers a kernel BUG_ON in f2fs_evict_inode when a root inode remains dirty after checkpoint re-enable due to insufficient free segments created by large-file operations during checkpoint=disable, leading to invalid opcode panic on unmount.

Why it matters to the business

Systems using f2fs (common in embedded, mobile, and storage devices) can experience unexpected kernel crashes and service disruption during normal unmount operations after specific file creation and deletion sequences, increasing operational downtime and potential data handling risks.

How an attack unfolds

An attacker with local access mounts an f2fs image with checkpoint disabled, creates a large file that exhausts free segments, deletes it, remounts with checkpoint enabled, then unmounts; the resulting dirty inode state in f2fs_evict_inode causes the BUG. No remote or privilege-escalation path is described.

How to fix it

Upgrade the Linux kernel to a version containing commit ac8aaf78bd039fa1be0acaa8e84a56499f79d721 which redirties the inode when free segments are insufficient during checkpoint disable. Rebuild and deploy the fixed kernel across affected systems; test f2fs mount/unmount workflows after upgrade.

How to confirm the fix worked

Confirm the running kernel contains commit ac8aaf78bd039fa1be0acaa8e84a56499f79d721 via git log or kernel version string; attempt the published reproduction steps (large file creation under checkpoint=disable followed by remount and unmount) and verify no BUG_ON occurs.

Typical attack path

1. Mount f2fs filesystem with checkpoint=disable
2. Create large file(s) until free segments are exhausted
3. Delete the file(s)
4. Remount with checkpoint=enable
5. Unmount the filesystem to trigger BUG_ON in f2fs_evict_inode

How to detect it

Search kernel logs for 'kernel BUG at fs/f2fs/inode.c:896' or 'f2fs_evict_inode' oops traces; inspect audit or system logs for sequences of mount/remount with checkpoint options followed by umount on f2fs volumes.

What your security team should do

• Prioritize kernel upgrade to the fixed commit on all systems using f2fs
• Review f2fs usage in embedded or high-availability deployments and schedule testing of checkpoint disable/enable workflows
• Monitor for kernel oops reports referencing f2fs_evict_inode until patches are applied