The world of filesystems is always full of interesting bugs, and every now and then, one slips through that could have disastrous consequences. Let’s take an exclusive look at CVE-2024-34027, a recently fixed vulnerability affecting the Linux kernel’s f2fs (Flash-Friendly File System). This post will help you understand in simple terms what went wrong, how it could be exploited, and how it was fixed, with code snippets and exploit guidance for educational purposes.

What Is f2fs and Why Does It Matter?

f2fs is a filesystem designed for NAND flash memory. It’s used on millions of Android devices, embedded systems, and even on desktops and servers where fast, modern disks are required. The Linux kernel has f2fs built-in for quite a while.

The Core of the Bug

At its heart, CVE-2024-34027 is a *race condition* in the compression subsystem of f2fs. Specifically, the reserve_compress_blocks() and release_compress_blocks() functions were not holding the necessary cp_rwsem (checkpoint read/write semaphore) locks. If an operation raced with a checkpoint (a crucial metadata update in a filesystem), this could corrupt critical metadata.

blkaddr in dnode (block address in a node)

- Inode fields (the core data structure pointing to files/directories)

.total_valid_block_count (a key counter keeping track of storage integrity)

Such corruption could cause data loss, security risks, or even total filesystem failure.

Here’s a simplified and exclusive look at how things used to be

/* compress.c - simplified buggy code */

void reserve_compress_blocks(struct f2fs_sb_info *sbi, int count) {
    // Updates storage metadata
    sbi->compress_blocks_reserved += count;
    // ... modifies dnode, inode, .total_valid_block_count
}

void release_compress_blocks(struct f2fs_sb_info *sbi, int count) {
    // Updates storage metadata
    sbi->compress_blocks_reserved -= count;
    // ... modifies dnode, inode, .total_valid_block_count
}

// elsewhere, these are called *without* locking cp_rwsem!

No lock is held: This means that while these functions run, a checkpoint (cp) might also be happening. If both modify the same structures, *boom*: a race condition, and silent data corruption.

The Fix: Lock It Right

The mainline Linux team fixed this by wrapping these function calls with the cp_rwsem lock. This lock ensures that only one thread can make these changes while checkpointing is happening.

Here’s what it looks like after the fix

#include <linux/rwsem.h>

void reserve_compress_blocks(struct f2fs_sb_info *sbi, int count) {
    down_write(&sbi->cp_rwsem); // LOCK
    sbi->compress_blocks_reserved += count;
    // Safely update metadata
    up_write(&sbi->cp_rwsem);   // UNLOCK
}

void release_compress_blocks(struct f2fs_sb_info *sbi, int count) {
    down_write(&sbi->cp_rwsem); // LOCK
    sbi->compress_blocks_reserved -= count;
    // Safely update metadata
    up_write(&sbi->cp_rwsem);   // UNLOCK
}

Now, any changes are locked during the operation, eliminating the race.

- The Patch (LKML)
- NVD Entry

In Theory

If an unprivileged user could force heavy compression activity (e.g., creating or deleting lots of compressed files), and simultaneously force repeated checkpoints (e.g., by unmounting/remounting or syncing the disk), they might heighten the chance for a race. If timed just right, this could corrupt filesystem metadata.

- In practical, default setups, this is *not* easily triggerable by regular users, but any malicious code running with disk access *might* cause damage, especially if they also have ways to trigger checkpoints (e.g., via sync, device unplug, or unmount).

Simplified Race Trigger PoC (NOT reliable, for education)

#!/bin/bash
# Prepare f2fs partition (not for prod use!)
mkfs.f2fs /dev/sdX
mount -t f2fs /dev/sdX /mnt/f2fs_test

# In one shell, write compressed files in a tight loop:
while true; do
  dd if=/dev/urandom of=/mnt/f2fs_test/testfile bs=1M count=1 conv=fsync
  rm /mnt/f2fs_test/testfile
done

# In another shell, force checkpoints/re-mount:
while true; do
  sync
  umount /mnt/f2fs_test; mount -t f2fs /dev/sdX /mnt/f2fs_test
done

*This can corrupt data or kill your filesystem! Do not run on systems with important data. This is for understanding, not for actual attack.*

Update your Linux kernel if you use f2fs

- Android/device vendors: push updates including this patch

Summary

CVE-2024-34027 is a scary reminder to always use locks for shared resources in kernel development. One missing lock led to a subtle but dangerous race that could eat your data—or worse. If you use f2fs and compression, make sure you’re patched.

For exclusive security analysis like this, stay tuned!


*Sources & More Reading:*
- Kernel.org commit log
- CVE-2024-34027 on NVD
- F2FS documentation

Timeline

Published on: 06/24/2024 14:15:11 UTC
Last modified on: 11/05/2024 15:35:13 UTC