Linux is one of the most widely used operating systems powering everything from web servers to smartphones. Security vulnerabilities in the Linux kernel have far-reaching consequences, potentially exposing millions of systems to risk. In 2024, a critical vulnerability was discovered and patched in the Linux kernel's libfs module, specifically in the function get_stashed_dentry(). This issue, tracked as CVE-2024-46801, could lead to a Use-After-Free (UAF) bug if an attacker managed to exploit the improper handling of Read Copy Update (RCU) protections.

This post explains CVE-2024-46801 in simple terms, provides key context, walks through vulnerable code, details the exploit path, and links to official sources.

Synopsis

The function get_stashed_dentry() in the Linux kernel's generic filesystem (libfs) tries to optimize how it accesses directory entries ("dentaries") by fetching previously saved (or "stashed") pointers. However, it failed to correctly acquire and obey RCU locking rules before accessing shared memory. This mistake could lead to dereferencing a pointer that was already freed (UAF), causing kernel memory corruption or information leaks.

Path to Issue

- Normal expectation: RCU ("Read Copy Update") is a mechanism in Linux used to let multiple threads read shared data safely while one may update it.
- Bug: Before this fix, the code used READ_ONCE(), which merely reads the memory value but does not communicate intent or rely on RCU protections.
- Consequence: During a race condition, one thread could free a dentry, another could read and use it without knowing it's gone—dangerous!

Patch Summary

The fix replaces READ_ONCE() with rcu_dereference(). This change not only ensures the right kernel memory barriers but also signals to kernel debugging tools ("lockdep") that RCU rules are expected.

Before the Patch

struct dentry *get_stashed_dentry(struct dentry **location)
{
    return READ_ONCE(*location);
}

After the Patch

struct dentry *get_stashed_dentry(struct dentry **location)
{
    return rcu_dereference(*location);
}

Full patch diff:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=f30c916e1a5

Force a scenario where get_stashed_dentry() would access a pointer to a freed dentry.

2. Arrange for kernel memory reclamation so that the freed memory could be reused/mapped controllably or contain attacker-controlled data.

If they succeed

- Memory Corruption: Kernel may operate on invalid memory, possibly escalating privileges or crashing.

Suppose

- A malicious unprivileged user triggers rapid mount and unmount events on a crafted filesystem, controlling dentry allocations.

A parallel process dereferences a stale dentry pointer using the buggy READ_ONCE() pattern.

- The attacker controls the timing and content of freed/reused memory, possibly controlling file attributes or leaking data.

While a simple proof-of-concept (PoC) is complex and kernel-version dependent, a high-level Python-style pseudo-PoC looks like this:

# Pseudocode! Not directly runnable, illustrates concept.
fork()
if child:
    # Spray allocations to force reuse of freed dentry memory
    for i in range(100000):
        open('/busyfs/file' + str(i), 'w')
else:
    # Repeatedly mount/umount to trigger dentry freeing
    for i in range(10000):
        mount('busyfs', '/mnt')
        umount('/mnt')

With race timing, this might have yielded memory corruption when the parent saw a stashed pointer to a freed-and-reused dentry.

Distros will roll out updates once merged.

Mitigation:
Update your systems! Watch your distro's security bulletins and apply kernel patches as soon as available.

References

- Upstream Patch Commit
- CVE-2024-46801 at CVE.org
- Linux Kernel RCU Documentation

Conclusion

CVE-2024-46801 is a technical vulnerability, but with big implications: kernel memory safety is critical. A single missed locking function could open up root privilege escalation on millions of computers. Thanks to rapid response, the kernel community closed this hole, but it’s a reminder that filesystem internals shouldn't be underestimated.

Timeline

Published on: 09/18/2024 08:15:06 UTC
Last modified on: 09/20/2024 17:18:17 UTC