CVE-2024-27034 uncovers a significant race condition vulnerability in the Linux kernel's F2FS (Flash-Friendly File System) compression code. The flaw could lead to filesystem data corruption under certain write patterns, especially during a sudden power loss or crash. This post breaks down the vulnerability in simple terms, illustrates how it can be exploited, and explains the official fix with sample code.

What is F2FS?

F2FS is a Linux-native file system tailored for NAND flash memory storage, like SSDs and eMMCs, and is widely used in consumer electronics and Android devices. The file system has built-in data compression features to save space and improve longevity. Core kernel code maintaining filesystem consistency is critical in these scenarios.

Vulnerability Explained

Raw Summary:
A locking bug in F2FS’s compression logic means the cp_rwsem (checkpoint read-write semaphore) was incorrectly released too early during "cluster" writes, allowing file data and metadata to be updated at different times. If a system crash or power loss occurs in between, the metadata might not match the actual file data on disk, resulting in subtle or catastrophic file corruption.

A compressed cluster is *overwritten* with a normal (uncompressed) cluster.

- The code drops the cp_rwsem too early, before updating the cluster’s metadata and persisting raw pages.
- If a crash or power-off happens, not only is user data at risk, but metadata about which blocks are compressed gets out of sync—a nightmare for recovering your files.

Vulnerable Code (Simplified)

Here’s a simplified, annotated version of the buggy logic, where the checkpoint lock is dropped too early:

// Bad: releases cp_rwsem too soon!
down_write(&sbi->cp_rwsem);
// code that prepares to overwrite a compressed cluster
up_write(&sbi->cp_rwsem);  // <-- Bug here: unlocks before true completion!

// Now f2fs_write_raw_pages() can run without the protection,
// leading to possible corruption if a crash occurs now
f2fs_write_raw_pages(...);

Effect:
If a partial write is persisted but checkpoint metadata isn’t, recovery after a crash may restore the wrong or incomplete cluster.

The Patch

The patch removes the premature unlock and ensures all cluster writes happen while the checkpoint lock is held:

down_write(&sbi->cp_rwsem);
// correctly protect entire overwrite operation
f2fs_write_raw_pages(...);
// only unlock after all is safely written
up_write(&sbi->cp_rwsem);

Reference patch:

- Official commit: f2fs: compress: fix to cover normal cluster write with cp_rwsem

How Could This Be Exploited?

While this is not a classic remote exploit, an attacker with local file write access—especially on a multi-user system or from a malicious app on Android—could:

Trigger repeated write patterns to compressed files.

2. Simultaneously cause I/O pressure, then force a sudden power-off or crash.
3. On reboot, the filesystem may recover to a corrupt state, manifesting as data loss, application instability, or privilege escalation via malformed file contents.

Imagine a user/app is writing non-compressed data into a compressed file cluster in a loop

import os

FILENAME = "/mnt/f2fs_testfile"
with open(FILENAME, "wb") as f:
    # Fill the initial file to trigger compression clusters
    f.write(os.urandom(4096 * 128))

# Overwrite a portion (potentially switching to normal cluster)
with open(FILENAME, "r+b") as f:
    f.seek(4096 * 10)
    for _ in range(100):
        f.write(os.urandom(4096 * 4))
        os.fsync(f.fileno())
        # Here, simultaneous power loss (SPOR) would exploit the window

print("Simulate crash now after some writes (power cycle device)")

Update Immediately:

Kernel 6.6.31 and 6.9.2 (and later) include the fix. View release notes

Test Your System:

If you rely on F2FS with compression (commonly on embedded or Android devices), prioritize updating the kernel.

References

- CVE Record: CVE-2024-27034
- Linus kernel commit log
- F2FS Project
- 6.6.31 stable kernel changelog

Conclusion

CVE-2024-27034 is a reminder of the subtle dangers lurking in fast-moving kernel filesystems, particularly with advanced features like transparent compression. A single misplaced lock can endanger terabytes of data. If your systems—or your users’ systems—use F2FS compression, update your kernels as soon as possible to avoid silent and hard-to-detect file corruption.


*Feel free to share or cite this post. For further questions, check the references above or file an issue with your OS/distribution kernel maintainers.*

Timeline

Published on: 05/01/2024 13:15:49 UTC
Last modified on: 05/04/2025 09:02:45 UTC