CVE-2026-43501

What it actually does

CVE-2026-43501 is a Linux kernel memory-corruption flaw in IPv6 RPL Source Routing Header processing. When the kernel decompresses, updates, and recompresses an RFC 6554 type-3 IPv6 Source Routing Header, the recompressed header can become larger than the received header. On non-final routing segments, the kernel did not always reserve enough packet headroom for both the expanded header and the rebuilt MAC header. This can cause skb metadata underflow/wraparound and an out-of-bounds write roughly 64 KiB beyond the packet buffer. Successful exploitation can trigger a kernel crash and may potentially allow privilege escalation or kernel-level code execution depending on memory layout, hardening, and exploit reliability.

Why it matters to the business

Affected Linux systems that process crafted IPv6 RPL routing-header traffic may be exposed to denial of service through kernel crashes, and potentially full host compromise if the memory corruption is weaponized. The operational risk is highest for internet- or untrusted-network-facing Linux systems with IPv6 enabled and for environments where routing-header traffic can reach hosts. Although the CVSS score is critical, EPSS is currently low and the issue is not listed in CISA KEV or known ransomware use, so prioritize remediation based on exposure: externally reachable IPv6 systems, network appliances, container hosts, and multi-tenant Linux infrastructure should be addressed first.

How an attack unfolds

An attacker sends a specially crafted IPv6 packet containing a type-3 RPL Source Routing Header. The packet is constructed so that, during RPL SRH processing, the destination-address swap reduces the common-prefix compression efficiency and causes the recompressed routing header to grow. Because vulnerable kernels did not reserve sufficient headroom before pushing the recompressed header and IPv6 header back into the packet buffer, the subsequent MAC-header rebuild can wrap the skb mac_header offset and perform an out-of-bounds write. In the common failure mode this results in a kernel oops, panic, or watchdog-triggered reboot. With additional exploit development, the same primitive may be investigated for controlled kernel memory corruption and possible code execution. No public exploitation or named threat-actor use is currently indicated by the provided intelligence.

How to fix it

Upgrade to a Linux kernel build that includes the upstream fix for the IPv6 RPL SRH headroom reservation issue, specifically the patch titled "ipv6: rpl: reserve mac_len headroom when recompressed SRH grows." Use the fixed kernel packages supplied by the operating system or appliance vendor; no exact package versions were provided in the input. Reboot systems after kernel updates unless live patching is explicitly available and confirmed to cover this issue. Where immediate patching is not possible, reduce exposure by filtering IPv6 routing headers at network boundaries where they are not required, blocking or dropping IPv6 Routing Header type 3 / RPL SRH traffic, disabling IPv6 on systems that do not need it, and limiting untrusted access to hosts that process IPv6 packets. For local or containerized attack-surface reduction, restrict CAP_NET_RAW, disable unprivileged user namespaces where operationally feasible, and prevent untrusted workloads from creating raw IPv6 packets.

How to confirm the fix worked

Confirm the running kernel version and vendor advisory status after remediation, not only the installed package version, because kernel fixes require the fixed kernel to be booted. Validate that the applied kernel contains the upstream RPL SRH headroom patch or the vendor backport. Check exposure by verifying whether IPv6 is enabled and whether IPv6 Routing Header type 3 traffic can reach the host. Network validation can include packet captures or firewall counters for IPv6 next-header 43 and routing type 3. If mitigations are used, test that routing-header type 3 packets are dropped before reaching vulnerable hosts. On hardened test systems only, a controlled proof-of-concept should no longer produce KASAN, kernel oops, panic, or logs referencing ipv6_rthdr_rcv, ipv6_rpl_srh_rcv, skb_mac_header_rebuild, or out-of-bounds writes.

Typical attack path

1. Identify Linux systems that accept IPv6 traffic and are reachable over an untrusted network path.
2. Send probe traffic to determine whether IPv6 routing headers, specifically Routing Header type 3 / RPL Source Routing Header, are accepted or forwarded to the target stack.
3. Craft an IPv6 packet with an RPL Source Routing Header whose compressed segment fields cause the recompressed header to be larger after the next-segment swap.
4. Deliver the packet to the vulnerable host or service path.
5. Trigger vulnerable skb headroom handling during ipv6_rpl_srh_rcv / ipv6_rthdr_rcv processing.
6. Cause kernel memory corruption, typically producing a crash or panic; in a more advanced exploit, attempt to shape the out-of-bounds write for kernel compromise.

How to detect it

Look for evidence in kernel logs, crash dumps, EDR telemetry, network IDS logs, firewall logs, and packet captures. Host-side evidence is likely to appear as kernel oops, panic, KASAN, or crash reports involving IPv6 extension-header processing functions such as ipv6_rthdr_rcv, ipv6_rpl_srh_rcv, skb_mac_header_rebuild, skb_push, or pskb_expand_head. Network-side evidence should focus on unusual or unexpected IPv6 packets using Next Header 43, especially Routing Header type 3 / RPL Source Routing Header, packets with nonzero Segments Left, and compressed RPL SRH fields such as CmprI=0 and high CmprE values. Because exploitation may only leave a crash artifact, correlate system reboots, kernel panics, or service outages with preceding IPv6 routing-header traffic. In environments with KASAN or debug kernels, search for slab-out-of-bounds or out-of-bounds write reports in IPv6 routing-header paths. There are no provided indicators of named threat actors, ransomware campaigns, or public exploit tooling, so detection should emphasize behavioral artifacts rather than actor-specific IOCs.

• ipv6_rpl_srh_rcv
• ipv6_rthdr_rcv
• skb_mac_header_rebuild
• skb_set_mac_header
• pskb_expand_head
• skb_push
• BUG: KASAN: slab-out-of-bounds
• BUG: KASAN: out-of-bounds
• OOB write in ipv6_rthdr_rcv
• kernel panic - not syncing
• Oops:
• IPv6 Routing Header
• Routing Header type 3
• RPL Source Routing Header
• Next Header: 43
• IP6 route type 3
• CmprI=0
• CmprE=15
• Segments Left

What your security team should do

• Inventory Linux systems with IPv6 enabled, prioritizing internet-facing, network-edge, virtualization, container-host, and multi-tenant systems.
• Apply vendor kernel updates that include the IPv6 RPL SRH headroom fix and reboot into the fixed kernel.
• Until patching is complete, block IPv6 Routing Header type 3 / RPL Source Routing Header traffic at perimeter, host firewall, and internal segmentation points unless explicitly required.
• Review whether IPv6 is required on exposed systems; disable it where it is not operationally needed.
• Restrict CAP_NET_RAW and untrusted raw-socket access, especially in containers and multi-user systems.
• Monitor kernel logs and crash telemetry for signs of IPv6 routing-header processing crashes or KASAN out-of-bounds write reports.
• Add IDS, Zeek, packet-capture, or firewall visibility for IPv6 next-header 43 with routing type 3 traffic.
• Treat unexplained kernel crashes following unusual IPv6 routing-header traffic as potentially suspicious and preserve crash dumps, packet captures, and logs.
• Track vendor advisories because exact fixed versions vary by distribution and may be delivered as backports without changing to a visibly new upstream kernel version.