CVE-2026-43501: Heap Out-of-Bounds Write in Linux Kernel IPv6 RPL Segment Routing Header Processing

The Linux kernel's networking stack implements support for the IPv6 Routing Protocol for Low-Power and Lossy Networks (RPL) Segment Routing Header (SRH) according to RFC 6554. This extension header allows routers to guide packets along designated paths in resource-constrained networks. The RPL implementation is situated inside the net/ipv6/exthdrs.c source file, with incoming packets routed through the ipv6_rpl_srh_rcv function. This function handles the parsing, decompression, and updates necessary for processing routing headers of Type 3.

To save bandwidth in low-power wireless mesh networks, RPL SRH employs an address compression scheme. It leverages the common prefix of successive IP addresses to avoid transmitting redundant prefix bytes. This compression is guided by parameters like CmprI and CmprE, which define the compression size for transit and exit segments. When a packet passes through an intermediate node, the destination address of the IPv6 header is swapped with the next active segment, and the SRH must be recompressed based on the new destination's relationship with subsequent segments.

During this segment-swapping process, the common prefix length between the newly selected destination address and remaining segments may shrink. This reduction in commonality forces the recompressed SRH to expand in size, requiring more bytes than the received packet had allocated. Under normal conditions, the kernel's network socket buffer (skb) must check and expand its available headroom to prevent subsequent layout operations from writing outside the allocated memory. The failure of the kernel to enforce this check under all processing conditions constitutes the core vulnerability defined as CVE-2026-43501.

The attack surface exposed by this vulnerability is accessible remotely via IPv6. If a vulnerable system is configured to process RPL extension headers, an unauthenticated network-based adversary can transmit malformed packets to trigger memory corruption. Because this vulnerability occurs at the kernel level within the network softirq context, its impact extends to complete system compromise. Security teams must treat the exposed surface as high-risk, especially in deployments using Internet of Things (IoT) edge routers or industrial automation devices running affected Linux distributions.

The root cause of CVE-2026-43501 is located in the inadequate gating logic for headroom expansion within the ipv6_rpl_srh_rcv function. When processing a received routing packet, the kernel decompresses the SRH, performs the segment swap, and recalculates the recompressed header size. If the swap reduces prefix-matching similarity, the new header (chdr) grows up to 8 additional bytes. To handle this expansion, the kernel must guarantee sufficient headroom space in the socket buffer before pushing the newly formatted headers back into the buffer.

In the vulnerable implementation, the invocation of pskb_expand_head was conditionally restricted. The code only performed this expansion check if the packet had reached its final destination, represented by the condition segments_left == 0. When a packet was received with intermediate hops remaining (segments_left > 0), the kernel completely bypassed the safety check, proceeding directly to execute skb_push on the socket buffer despite the increased length of the recompressed header.

Compounding this issue, the parameters passed to pskb_expand_head even when segments_left == 0 was met were structurally deficient. The function requested an expanded size that only covered the network layer headers, specifically sizeof(struct ipv6hdr) and the calculated size of the new RPL header. It failed to account for the media access control (MAC) header size stored in skb->mac_len. When skb_push subtracted the header size, the remaining distance between the start of the buffer (skb->head) and the data pointer (skb->data) became less than the size of the MAC header.

The final stage of the corruption occurs when the kernel attempts to rebuild the link-layer header. Inside skb_mac_header_rebuild, the helper function skb_set_mac_header(skb, -skb->mac_len) is invoked to update the MAC pointer. This operation subtracts the mac_len from the offset relative to the data pointer. Because the remaining headroom is smaller than mac_len, this mathematical operation underflows the unsigned 16-bit integer representation of skb->mac_header, wrapping the value to roughly 65530. When a subsequent memmove operation copies the MAC data into skb_mac_header(skb), it executes a write approximately 64 KiB beyond the end of the allocated socket buffer, leading to an out-of-bounds slab write.

A code-level comparison between the vulnerable and patched implementations of ipv6_rpl_srh_rcv illustrates how the validation gap was closed. The vulnerable code path relied entirely on the status of segments_left to decide whether to expand the socket buffer headroom. This implementation assumed that intermediate routing steps would never exceed the pre-allocated headroom, ignoring the potential for common-prefix reduction during segment swapping. The following code snippet shows the flawed gating logic where the headroom check is restricted to the final hop:

// Vulnerable implementation in net/ipv6/exthdrs.c
if (unlikely(!hdr->segments_left)) {
    if (pskb_expand_head(skb, sizeof(struct ipv6hdr) + ((chdr->hdrlen + 1) << 3), 0, GFP_ATOMIC)) {
        __IP6_INC_STATS(net, ip6_dst_idev(skb_dst(skb)), IPSTATS_MIB_OUTDISCARDS);
        kfree_skb(skb);
        return -1;
    }
    oldhdr = ipv6_hdr(skb);
}

The patched implementation removes the unsafe assumption by checking the available headroom dynamically. It introduces the chdr_len variable to store the exact size of the newly formatted headers. It then evaluates whether the remaining headroom is less than chdr_len plus the MAC header length (skb->mac_len), regardless of the segments_left count. If the headroom is insufficient, pskb_expand_head is called to allocate the necessary space, as detailed below:

// Patched implementation in net/ipv6/exthdrs.c
chdr_len = sizeof(struct ipv6hdr) + ((chdr->hdrlen + 1) << 3);
if (unlikely(!hdr->segments_left ||
             skb_headroom(skb) < chdr_len + skb->mac_len)) {
    if (pskb_expand_head(skb, chdr_len + skb->mac_len, 0,
			     GFP_ATOMIC)) {
        __IP6_INC_STATS(net, ip6_dst_idev(skb_dst(skb)), IPSTATS_MIB_OUTDISCARDS);
        kfree_skb(skb);
        return -1;
    }
    oldhdr = ipv6_hdr(skb);
}

By modifying the conditions and incorporating skb->mac_len into the allocation size request, the kernel guarantees that the socket buffer has sufficient memory space to perform both the network layer push and the link layer MAC header rebuild. This prevents the mathematical wrapping of the MAC header offset pointer. The diagram below illustrates the packet buffer state transition leading to the out-of-bounds write:

The exploitation of CVE-2026-43501 requires the attacker to construct and inject a malformed IPv6 packet containing a Type 3 RPL Segment Routing Header. For local privilege escalation, an attacker can leverage an unprivileged raw socket. On systems where user namespaces or administrative configurations allow opening raw sockets (using AF_INET6 and SOCK_RAW with the IPV6_HDRINCL option), an attacker can inject custom headers directly over the loopback interface (lo). This bypasses several hardware-level network controls and exposes the vulnerable code path immediately.

To execute the attack, the adversary must construct a packet layout containing an RPL SRH with two segments where segments_left is set to 1. The compression flags are set to CmprI = 0 and CmprE = 15. The critical step in triggering the vulnerability is configuring the first segment's prefix to differ from the destination address specified in the outer IPv6 header (seg[0][0] != daddr[0]). This mismatch forces the recompressed header size to expand during the routing transition on the intermediate node.

When the vulnerable system receives and processes this crafted packet, the segment-swapping step in ipv6_rpl_srh_rcv reduces the common-prefix length, causing the recompressed header to grow in size. Because segments_left is greater than zero, the kernel skips the headroom expansion check. The subsequent execution of skb_push consumes more headroom than is available, resulting in the offset pointer wrapping. The subsequent call to skb_mac_header_rebuild performs a 14-byte write into the wrapped offset address.

In remote attack scenarios, the crafted packet must be sent to an interface that is actively listening for and processing RPL packets. Since RPL is primarily deployed in specific network topologies like low-power IoT networks, the remote attack surface depends heavily on system configuration. If the vulnerable device has RPL enabled and processes the incoming packet, the resulting memory corruption will either crash the system or allow the execution of payload code depending on the state of the kernel heap.

The security impact of CVE-2026-43501 is classified as critical, as reflected by its CVSS v3.1 score of 9.8. Because the vulnerability resides within the packet-processing path of the kernel's network stack, it can be triggered by sending network packets without requiring prior authentication or user interaction. An attacker only needs network reachability to the target system's IPv6 interface to initiate the attack, making it highly dangerous for exposed devices.

The out-of-bounds write is approximately 14 bytes in size, corresponding to the MAC header length, and is located roughly 64 KiB past the start of the socket buffer's memory allocation (skb->head). This specific distance means that instead of corrupting the socket buffer's metadata immediately, the write corrupts adjacent slab objects allocated within the kernel heap. The corrupted structures may belong to other processes, network connections, or critical kernel subsystems.

Depending on the configuration of the kernel heap at the time of the attack, the memory corruption can manifest in two primary ways. The most common outcome is a kernel panic, leading to a complete denial of service (DoS) for the affected host. However, if an attacker can systematically organize the kernel heap (a process known as heap grooming), they can align sensitive data structures, such as credentials, task structures, or function pointers, with the target 64 KiB offset. Corrupting these structures can allow the attacker to escape containerized environments or elevate privileges to root.

The primary remediation strategy for CVE-2026-43501 is upgrading the Linux kernel to a patched version. Subsystem maintainers have backported the security fix to all active long-term support (LTS) stable branches. Administrators should verify their kernel version and plan upgrades to the following minimum patched releases: 5.10.258, 5.15.209, 6.1.175, 6.6.140, 6.12.86, 6.18.27, or 7.0.4. Applying these updates eliminates the validation gap and prevents the underflow condition entirely.

In operational environments where immediate kernel patching is not feasible due to uptime requirements or compliance procedures, network-level mitigations can be implemented. Since RPL is a specialized routing protocol designed primarily for constrained Internet of Things networks, it is rarely required in standard enterprise servers or cloud environments. Network administrators can safely drop incoming IPv6 packets containing RPL Routing Headers (Type 3) at the firewall layer.

To enforce this mitigation using legacy ip6tables configurations, administrators can apply a global drop rule targeting the specific routing header type. The following command drops all incoming packets containing the RPL routing header before they reach the kernel's protocol handlers:

ip6tables -A INPUT -m rt --rt-type 3 -j DROP

For modern Linux deployments utilizing the nftables framework, a similar rule can be appended to the input filter chain. This provides an efficient, hardware-accelerated drop mechanism that prevents the malformed headers from triggering the vulnerable code path:

nft add rule ip6 filter input rt type 3 drop

These firewall rules provide immediate protection against both local and remote exploitation vectors without requiring system reboots or causing operational disruption to non-RPL network traffic.