In early 2024, a critical vulnerability surfaced in the Linux kernel’s netfs and fscache subsystems, tracked as CVE-2024-26612. This bug didn’t just pose a risk of data corruption, but could crash your whole system — all because of the order of a simple check and dereference.

In this post, I’ll walk you through what happened, how the code looked before and after, how you could have potentially triggered this “Oops” (crash), references to the official fix, and some takeaways for everyday developers. Whether you’re running Linux at home or in the cloud, it’s worth understanding.

Let’s break it down without jargon

- The fscache module is responsible for caching network file systems — speeding up access to remote data.

The function fscache_put_cache() is called when it needs to release (free) a cache object.

- This function would sometimes touch (dereference) a pointer called cache *before* checking if it was valid.

If cache was bad (set to an error value or NULL), this would cause a kernel panic or “Oops”.

In general programming, you should always check if something is valid before trying to use it. Here, the check came *too late*.

Here’s a simplified version of what was happening

void fscache_put_cache(struct fscache_cache *cache, int why)
{
    // Dereference "cache" first
    pr_debug("Put cache %s [ref %d]\n", cache->tag->name, refcount_read(&cache->ref));
 
    // Only now do we check
    if (IS_ERR_OR_NULL(cache))
        return;

    // ...rest of the function...
}

See the problem? If cache is NULL (which means it doesn’t point to a valid memory structure) or an error pointer, trying to access cache->tag or cache->ref will crash the kernel.

Here's how the fixed function looks (simplified for clarity)

void fscache_put_cache(struct fscache_cache *cache, int why)
{
    // Check first!
    if (IS_ERR_OR_NULL(cache))
        return;

    pr_debug("Put cache %s [ref %d]\n", cache->tag->name, refcount_read(&cache->ref));
   
    // ...rest of the function...
}

Now, if cache is bad, it just exits without trying to access it.

How Could This Be Exploited?

- If an attacker could trigger fscache_put_cache() with a NULL pointer or an error pointer, they could crash the kernel.
- In real systems, that might mean a local user (possibly with specific capabilities or after exploiting some path to reach this function) could cause a deliberate denial-of-service.
- No privilege escalation, but any crash in kernel code is considered bad — especially in shared systems.

Official patch:

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=728c4427c3ed
- Bug tracker / Kernel archives discussion:
https://lore.kernel.org/all/20240226132338.84723-1-dhowells@redhat.com/

CVE page:

https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2024-26612

Here's a *theoretical* way you could hit the crash, by passing a bad pointer

// Dangerous: Only for demonstration
fscache_put_cache(NULL, ); // Would crash before the fix

In practice, this happens if other kernel bugs cause bad values, or due to race conditions, so direct exploitation is rare — but possible.

What Can You Do?

- Update your kernel! If you use fscache, especially on network filesystems (NFS, AFS, CacheFS, etc.), make sure your kernel is updated past this patch. All major distros will have picked this up in their updates after February/March 2024.
- If you manage servers or containers at scale, consider automated kernel patching or live-patching tools.

Final Thoughts

CVE-2024-26612 reminds us that basic checks in code matter. One line out of order can put an entire system at risk. Thanks to the kernel developers for catching and fixing it fast.

References

- Linux kernel patch commit 728c4427c3ed
- CVE-2024-26612 entry on Mitre

*If you have questions or want more details for your particular setup, let me know in the comments!*

Timeline

Published on: 03/11/2024 18:15:19 UTC
Last modified on: 11/06/2024 16:35:12 UTC