On June 2024, the Linux community patched a vulnerability found in the kernel’s key management subsystem: CVE-2024-47743. Though it may sound obscure, this bug could easily crash your Linux system—or worse—if certain conditions were met. In this post, I’ll walk you through what went wrong, how it was fixed, and provide simple code examples to help you understand and, if you maintain Linux systems or develop kernels, keep you safe.

What is CVE-2024-47743?

CVE-2024-47743 is a vulnerability in the *KEYS* subsystem of the Linux kernel. It was discovered by the Linux Verification Center using the Svace static analysis tool.

In simple terms, it’s a NULL pointer dereference. If a certain function (find_asymmetric_key) was called with all its ID arguments set to NULL, the Linux kernel would throw a warning—then promptly crash with an “oops” (kernel panic) right after. This could be triggered by an unprivileged user or process if permitted access, causing a denial of service.

The bug is in the following function

key_ref_t find_asymmetric_key(
    struct key *keyring, 
    const char *id_, 
    const char *id_1, 
    const char *id_2, 
    bool partial)
{
    if (!id_ && !id_1 && !id_2)
        WARN(...); // emit warning
    // ... then, even if all IDs are NULL ...
    some_function(*id_2); // oops! Null pointer dereference
    // Rest of function...
}

If all parameters (id_, id_1, id_2) are passed as NULL, the code does a warning (WARN()), but later tries to dereference id_2 anyway. Since id_2 is still NULL, the kernel crashes.

Exploit Details

If you want to see how this could be exploited (for testing or research purposes only!), here’s pseudocode in userspace that would trigger the bug via the keyctl syscall:

#include <keyutils.h>
#include <unistd.h>

int main() {
    // All IDs NULL - intentionally triggering the bug, if unpatched
    key_serial_t key;
    // Warning: The real kernel interface is more complex. 
    // This illustrates technique, not exploit reliability.
    // Do NOT run on production systems!

    key = find_asymmetric_key(NULL, NULL, NULL, NULL, false);
    // After this, the kernel would crash if unpatched!
    return ;
}

In practice, access controls minimize the risk for unprivileged users. But on custom or embedded systems, or in environments where the kernel keyring syscall is available, this could be used to knock out machines with no privilege escalation needed.

The Fix

The patch adds a simple missing check before dereferencing any of the three pointers.

Core Patch (C Snippet)

// Before:
if (!id_ && !id_1 && !id_2)
    WARN(...);
// ... later ...
some_function(*id_2); // unsafe!

// After:
if (!id_ && !id_1 && !id_2)
    WARN(...);
else if (!id_2)
    return ERR_PTR(-EINVAL);
// From here on, id_2 is guaranteed safe to use!

This prevents the code from ever touching a NULL argument and makes sure the warning shows up only in the right place.

References and Further Reading

- Original Commit Patch
- Linux Verification Center Announcement
- CVE-2024-47743 on NVD (when published)
- Svace Static Analysis Tool

Update your kernel: Make sure you’re running a kernel version patched after June 2024.

- Limit keyctl syscall use: Restrict access via seccomp or LSM modules if you don’t use kernel keyrings.

Conclusion

Null pointer dereferences seem like the most boring class of bugs, but in kernel space, they can bring down entire systems. CVE-2024-47743 shows how even “benign” mistakes can have critical consequences. If your system does cryptography via keyctl or exposes kernel keyring interfaces, patch as soon as possible, and happy hacking—but always stay safe!


*Exclusive for this blog. If you found this useful, check the links, and stay tuned for more vulnerability writeups from the edge of open source!*

Timeline

Published on: 10/21/2024 13:15:04 UTC
Last modified on: 11/05/2024 09:49:49 UTC