The Linux kernel’s flexibility and power owe much to its many filesystems, and F2FS, the Flash-Friendly FileSystem, is often used on modern mobile phones and embedded devices. But like all complex software, sometimes bugs can creep in — and CVE-2024-35844 is a perfect example involving compressed files and space reservations.

In this explainer, we’ll break down what happened, how it could cause real-world problems (even bricking files you care about!), how it was fixed — and what you should do about it. We'll use plain English, real output, and code snippets based on the current patch. Let's dig in.

What’s CVE-2024-35844? (Vulnerability Summary)

CVE-2024-35844 is a vulnerability in the Linux kernel’s F2FS module. When you were using compressed files on devices where the storage is almost full, a miscount of reserved compression blocks could leave some files unrecoverable by fsck (the filesystem check and repair tool). This bug specifically happened when a file only needed one direct_node (a file layout concept), then ran out of space.

If you tried to reserve compressed blocks for such a file when storage was full, the internal block count would get out of sync — so, after a reboot, even fsck couldn’t fix it. That’s pretty bad: in a worst-case, *your file would be broken for good*.

How Did This Manifest? (Symptoms and PoC)

Here’s a real sequence from a Unisoc device using the f2fs_io tool, illustrating the problem. You don’t need special exploits — it’s a logic problem:

# Compress a file on an almost full F2FS partition
unisoc # ./f2fs_io compress test.apk

# Check disk space
unisoc # df -h | grep dm-48
/dev/block/dm-48 112G 112G 1.2M 100% /data

# Release compress blocks
unisoc # ./f2fs_io release_cblocks test.apk
924

# Space does not free as expected
unisoc # df -h | grep dm-48
/dev/block/dm-48 112G 112G 4.8M 100% /data

# Stress disk space even more
unisoc # dd if=/dev/random of=file4 bs=1M count=3
3145728 bytes (3. M) copied, .025 s, 120 M/s
unisoc # df -h | grep dm-48
/dev/block/dm-48 112G 112G 1.8M 100% /data

# Now, try to reserve compression blocks
unisoc # ./f2fs_io reserve_cblocks test.apk
F2FS_IOC_RESERVE_COMPRESS_BLOCKS failed: No space left on device

# Reboot and try again
adb reboot
unisoc # df -h | grep dm-48
/dev/block/dm-48 112G 112G 11M 100% /data

unisoc # ./f2fs_io reserve_cblocks test.apk
              # Expected: this should not be zero!

If you now try to repair the filesystem, fsck won’t know that blocks are missing or wrongly counted — so your file remains broken.

Why Did This Happen? (A Simple Explanation)

The bug was in the F2FS compression code when a file only needed a single direct_node (i.e., a small file). If you ran out of space halfway through a “reserve blocks” operation, the code returned an -ENOSPC (No space left on device) error and *skipped* accounting for some reserved blocks.

This left the internal reserved_blocks counter at , when it really should have been nonzero. Later, tools like fsck would think everything was fine, and not attempt a repair — even though the file was in an inconsistent, potentially unrecoverable state.

The (Very Simple) Patch

The maintainers fixed this by making sure that, when the “out of space” (ENOSPC) condition happens on a single direct_node file, the filesystem flag that triggers a fsck (“filesystem check needed”) is always set.

Here’s the essence of the fix (simplified for clarity)

if (ret == -ENOSPC) {
    // Before: fsck flag not set, so recovery didn't happen
    set_sbi_flag(F2FS_SB(sb), SBI_NEED_FSCK);  // NOW always set on ENOSPC
    return ret;
}

This ensures that, after a reboot, fsck will actually run and correct the reserved_blocks count — so your file is at least repairable.

With the new patch in place, here’s how the system behaves

unisoc # df -h | grep dm-48
/dev/block/dm-48 112G 112G 1.8M 100% /data

# The same reserve attempt while out of space
unisoc # ./f2fs_io reserve_cblocks test.apk
F2FS_IOC_RESERVE_COMPRESS_BLOCKS failed: No space left on device

# Reboot
adb reboot

# Now, fsck auto-runs, fixes the miscount!
unisoc # df -h | grep dm-48
/dev/block/dm-48 112G 112G 11M 100% /data

# Retry reserve
unisoc # ./f2fs_io reserve_cblocks test.apk
924    # Corrected! The reserved block count is now correct.

Should I Worry? What To Do

Who’s affected:
If you’re running Linux with F2FS and use compressed files, especially on storage-constrained systems, this bug could leave files hooked in a bad state. Most desktop/server users are *not* affected, but phone/tablet manufacturers and users of embedded devices could be.

What to do:

Upgrade your kernel to a version with this fix.

- If you manage Android/IoT devices or storage appliances using F2FS, make sure your vendor shipped or backported the patch.
- If you experience “unexpected file corruption” or broken files on *full* F2FS volumes, a patched kernel plus a reboot will let fsck do its repair job.

References and Further Reading

- Original commit patch (kernel.org)
- F2FS Mailing List Discussion
- CVE-2024-35844 at NVD
- F2FS tools documentation

Bottom Line

CVE-2024-35844 is a subtle but important bug in how F2FS handled compression block reservation when storage space is low. The fix is simple but crucial: it ensures your filesystem knows when it needs fixing, so tools like fsck can *actually* do their job.

If you maintain or use Linux devices that might run short on flash space, upgrade your kernel — and sleep a little easier knowing your compressed files won’t go unrepairable!

Timeline

Published on: 05/17/2024 15:15:21 UTC
Last modified on: 05/04/2025 09:06:41 UTC