---

Linux users and sysadmins, here’s an important update about a recent kernel vulnerability now tracked as CVE-2024-41935. This issue was found and resolved in the Flash-Friendly File System (f2fs) implementation of the Linux kernel. In this post, we’ll break down the bug, show the technical details, and walk you through what led to the potential kernel hang — with easy-to-understand code samples and references.

What Is CVE-2024-41935?

The CVE-2024-41935 vulnerability affects systems running f2fs (Flash-Friendly File System) on the Linux kernel. It centers around how the kernel tries to shrink so-called "extent trees," which are data structures tracking file block allocations, specifically when there’s a large number of extent nodes.

Here’s the key: shrinking these data structures was done while holding a rwlock (read-write lock), but if the tree had lots of nodes, the operation could run for a long time, resulting in the rwlock being held way too long. That meant other threads or kernel components trying to access or modify the extent tree would get blocked. In a worst-case scenario? The whole kernel would hang.

In earlier versions, the shrinker logic looked something like this (simplified for clarity)

write_lock(&et->lock);
struct rb_node *node = rb_first(&et->root);
while (node) {
    struct extent_node *en = rb_entry(node, struct extent_node, rb_node);
    // Remove node
    node = rb_next(node);
    // Potentially slow, especially with thousands of nodes!
}
write_unlock(&et->lock);

If you had a large extent tree (think a busy database or a file server), this loop could iterate *thousands* of times, holding the rwlock through the whole thing.

The Fix: Batch Shrinking

The patch changes the shrink process to operate in batches. Instead of grabbing the lock and removing everything at once, it locks, clears a small batch, unlocks, and then repeats as necessary. That way, other threads get a chance to acquire the lock in between.

Patched code snippet

#define SHRINK_BATCH_SIZE 16

do {
    int cnt = ;
    write_lock(&et->lock);
    while (cnt < SHRINK_BATCH_SIZE && !RB_EMPTY_ROOT(&et->root)) {
        struct rb_node *node = rb_first(&et->root);
        struct extent_node *en = rb_entry(node, struct extent_node, rb_node);
        // Remove and free node here
        cnt++;
    }
    write_unlock(&et->lock);
    cond_resched();
} while (!RB_EMPTY_ROOT(&et->root));

Now, each lock hold is short, making hangs vastly less likely.

How Could It Be Exploited?

While this bug cannot be weaponized for code execution or privilege escalation, it can be abused as a local Denial of Service (DoS).

Attack scenario:
- A malicious local user, or a runaway program, allocates massive numbers of files (with unique blocks).

You can spoof a problematic state (in a safe environment!) like this

# Fill f2fs partition with thousands of small files
mkdir /mnt/f2fs-test
for i in $(seq 1 50000); do
  touch /mnt/f2fs-test/file_$i
done

# Delete all files suddenly; trigger extent tree shrink
rm /mnt/f2fs-test/file_*

With the unpatched kernel, you’d see high stalls around disk I/O, and even ls, cd, etc. would hang for ages.

Kernel commit (the patch):

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=408d7999f1c5

CVE Details:

https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2024-41935 (will be live soon)
OSS-security Mailing List

f2fs Developer Docs:

https://www.kernel.org/doc/html/latest/filesystems/f2fs.html

What Should I Do?

- Patch your kernel: If you use f2fs, upgrade ASAP to a kernel with this batch shrink fix (5.19+, or your vendor’s secure build).
- Monitor your systems: Watch for unusual I/O stalls on f2fs mounts.
- Educate users: Guard multi-user or exposed systems; some users may intentionally or accidentally trigger the bug.

TL;DR

CVE-2024-41935 is a Linux f2fs filesystem bug causing the kernel to hang when shrinking huge extent trees. Fix is in mainstream kernels. Patch ASAP to keep your systems stable and avoid lock-induced stalls!

Timeline

Published on: 01/11/2025 13:15:21 UTC
Last modified on: 05/04/2025 09:22:08 UTC