CVE-2024-36901: Linux Kernel Use-After-Free Vulnerability

CVE-2024-36901 Overview

CVE-2024-36901 is a NULL pointer dereference vulnerability in the Linux kernel's IPv6 networking stack. The vulnerability exists in the ip6_output() function where ip6_dst_idev() can return NULL under certain conditions. While most places in the IPv6 stack handle a NULL idev gracefully, this specific code path does not perform the necessary validation, leading to a general protection fault when the NULL pointer is dereferenced.

The vulnerability was discovered through syzbot, a kernel fuzzing system, which identified that the lack of NULL checking in ip6_output() at line 237 of net/ipv6/ip6_output.c could trigger a kernel crash. This issue affects systems with IPv6 networking enabled, particularly those using SCTP (Stream Control Transmission Protocol) for network communications.

Critical Impact

Local attackers with low privileges can trigger a kernel panic, causing complete system denial of service. This vulnerability can be exploited through the SCTP protocol stack during connection establishment.

Affected Products

• Linux Kernel (multiple versions prior to the security patches)
• Systems with IPv6 networking stack enabled
• Systems using SCTP protocol for network communications

Discovery Timeline

• 2024-05-30 - CVE-2024-36901 published to NVD
• 2024-11-21 - Last updated in NVD database

Technical Details for CVE-2024-36901

Vulnerability Analysis

This vulnerability is classified as CWE-476 (NULL Pointer Dereference). The root cause lies in insufficient validation of the return value from ip6_dst_idev() within the ip6_output() function. When this function returns NULL, the subsequent code attempts to access memory at an invalid address, triggering a general protection fault.

The kernel crash trace reveals the issue occurs at offset 0x231 in ip6_output(), specifically when attempting to read from memory range 0x00000000000005e0-0x00000000000005e7. This indicates the code is trying to access a member of the inet6_dev structure through a NULL pointer, resulting in a non-canonical address access that KASAN (Kernel Address Sanitizer) catches as a null-ptr-deref.

The call trace shows the vulnerability can be triggered through the SCTP connection path: __sys_connect → sctp_inet_connect → sctp_primitive_ASSOCIATE → sctp_do_sm → sctp_outq_flush → sctp_packet_transmit → sctp_v6_xmit → ip6_xmit → ip6_output. This chain demonstrates that a local user initiating an SCTP connection over IPv6 can trigger the vulnerable code path.

Root Cause

The vulnerability stems from a missing NULL pointer check in the ip6_output() function. While most IPv6 stack functions properly validate the return value of ip6_dst_idev(), this particular location assumed the function would always return a valid pointer. The ip6_dst_idev() function retrieves the inet6_dev structure associated with a destination, but under certain race conditions or edge cases involving route lookups, it can legitimately return NULL.

The fix adds proper NULL checking before accessing the idev structure, consistent with how other parts of the IPv6 stack handle this scenario.

Attack Vector

The attack vector is local, requiring an authenticated user with low privileges to exploit. The attacker needs the ability to create network sockets and initiate connections. The exploitation path involves:

1. Creating an SCTP socket with IPv6 addressing
2. Initiating a connection that triggers packet transmission through the vulnerable ip6_output() code path
3. The system attempts to send a packet when the destination's inet6_dev is in an invalid state
4. The NULL pointer dereference causes a kernel panic, resulting in system-wide denial of service

No remote exploitation path exists for this vulnerability, and there is no impact on confidentiality or integrity—only availability is affected through the denial of service condition.

Detection Methods for CVE-2024-36901

Indicators of Compromise

• Unexpected kernel panic messages referencing ip6_output+0x231 or similar offsets in the IPv6 output path
• KASAN reports showing null-ptr-deref in the range 0x00000000000005e0-0x00000000000005e7
• System crashes with call traces involving SCTP packet transmission over IPv6
• Repeated system reboots without apparent hardware cause, especially on systems with active SCTP/IPv6 usage

Detection Strategies

• Monitor kernel logs for general protection faults originating from net/ipv6/ip6_output.c
• Deploy KASAN-enabled kernels in development/staging environments to detect NULL pointer dereferences
• Use eBPF-based monitoring to track calls to ip6_output() and detect anomalous behavior patterns
• Implement crash dump analysis to identify patterns consistent with this vulnerability

Monitoring Recommendations

• Enable kernel crash dump collection (kdump) to capture diagnostic information when panics occur
• Configure syslog forwarding to centralized logging systems for correlation of crash events
• Monitor system uptime metrics for unexpected reboot patterns that may indicate exploitation attempts
• Review SCTP connection logs for unusual activity from local users

How to Mitigate CVE-2024-36901

Immediate Actions Required

• Apply the security patches from the Linux kernel stable branches immediately
• Prioritize patching systems that use SCTP over IPv6 for network communications
• If patching is not immediately possible, consider restricting SCTP socket creation to trusted users
• Monitor affected systems for unexpected crashes until patches are applied

Patch Information

The Linux kernel maintainers have released patches to address this vulnerability across multiple stable branches. The fix adds proper NULL pointer validation in the ip6_output() function before accessing the inet6_dev structure.

Patches are available from the following kernel git commits:

• Kernel Git Commit 4db783d68b9b
• Kernel Git Commit 55f7eb4001ef
• Kernel Git Commit e31b25cc2066
• Kernel Git Commit ea0cb87402f7

Organizations should update to kernel versions that include these patches through their distribution's package manager or by compiling from the updated kernel source.

Workarounds

• Restrict SCTP module loading if SCTP functionality is not required: echo "install sctp /bin/false" >> /etc/modprobe.d/disable-sctp.conf
• Use kernel module blocklisting to prevent SCTP from loading automatically
• Implement strict user access controls to limit who can create raw network sockets
• Consider network namespace isolation for untrusted workloads to limit blast radius

# Disable SCTP module loading as a temporary mitigation
echo "install sctp /bin/false" | sudo tee /etc/modprobe.d/disable-sctp.conf
echo "install sctp_diag /bin/false" | sudo tee -a /etc/modprobe.d/disable-sctp.conf

# If SCTP module is already loaded, it cannot be unloaded if in use
# Schedule a maintenance window to reboot with the new configuration

# Verify SCTP is disabled after reboot
sudo modprobe sctp 2>&1 | grep -q "install /bin/false" && echo "SCTP disabled" || echo "SCTP may still load"