CVE-2026-80976

What it actually does

The Linux kernel SRv6 path fails to reset the IPv6 control block (IP6CB) after outer-header decapsulation. End.DX6 and End.DT6 then deliver the inner IPv6 packet to ip6_protocol_deliver_rcu() with a stale, inflated nhoff and leftover extension-header flags from Hop-by-Hop and Destination Options on the outer packet. That offset is applied to the shorter inner skb, causing a slab out-of-bounds read past the skb head. The result is kernel memory corruption that can panic the host and, given the assigned high-severity rating, may be further abused for kernel information disclosure or arbitrary kernel-context execution.

Why it matters to the business

Hosts that terminate SRv6 (segment routing over IPv6)—including routers, telco/cloud overlays, and Linux systems that allow local SID installation—can be crashed or fully compromised, causing outages, kernel-level takeover, and follow-on lateral movement. The issue is not listed in CISA KEV, is not associated with ransomware campaigns, and EPSS remains low and flat (~0.0076 over 30 days) with no public exploit maturity about 20 days after publication. Residual risk is still high wherever SRv6 End.DT6/End.DX6 is reachable, because a successful kernel compromise is a full host loss.

How an attack unfolds

An attacker needs a Linux node that will process a packet toward a local SRv6 End.DT6 or End.DX6 SID. That can be a network-facing SRv6 endpoint, or a local unprivileged user who installs a SID from a user/net namespace and injects traffic. The attacker sends an outer IPv6 packet that stacks Hop-by-Hop and Destination Options (to leave a large nhoff in IP6CB), an SRH targeting the SID, and a minimal inner IPv6 packet. decap_and_validate() strips the outer SRv6 headers but leaves IP6CB uncleared. The inner packet is handed to the IPv6 input path; ip6_protocol_deliver_rcu() uses the stale offset and reads off the end of the skb. Depending on allocator layout this yields a kernel oops/DoS or a primitive that can be turned into leak or code execution. No named threat actors or in-the-wild campaigns are associated with this CVE.

How to fix it

Patch to a Linux kernel that includes the upstream fix “seg6: reset IP6CB after IPv6 decapsulation.” That change clears IP6CB after inner-IPv6 decap, restores the incoming interface index via IP6CB(skb)->iif and the IP6SKB_L3SLAVE flag (needed for VRF/L3-master correctness), and sets nhoff to the inner IPv6 base-header nexthdr field. Consume your distribution’s kernel update that backports this commit; no package-specific fixed versions were supplied with this record. Until you can patch: disable unused SRv6 local SID / lwtunnel processing; restrict who can add encap seg6local End.DT6/End.DX6 routes; block unprivileged user namespaces from creating net namespaces that program lightweight tunnels; and drop IPv6 routing-header type 4 at the edge if SRv6 is not required.

How to confirm the fix worked

Confirm the running kernel changelog or vendor advisory contains “seg6: reset IP6CB after IPv6 decapsulation” (or the equivalent stable backport). After upgrade, verify End.DT6/End.DX6 still forward inner IPv6 correctly, including VRF/L3-slave iif preservation. Inventory systems with CONFIG_IPV6_SEG6_LWTUNNEL or live `encap seg6local` routes, and review whether unprivileged user namespaces are permitted. Do not validate by reproducing the out-of-bounds read on production kernels.

Typical attack path

1. Discover a Linux host with SRv6 local SIDs (End.DT6 or End.DX6) or the ability for an unprivileged namespace to install them
2. Obtain a path to that SID (routed SRv6 traffic, or local packet injection after installing a SID)
3. Send an outer IPv6 packet with Hop-by-Hop and Destination Options, an SRH aimed at the local SID, and a short inner IPv6 packet
4. Kernel decapsulates SRv6, retains stale IP6CB nhoff/flags, and delivers the inner packet to IPv6 input
5. ip6_protocol_deliver_rcu() performs an out-of-bounds read; the host panics or the primitive is reused for kernel memory disclosure or privilege escalation

How to detect it

This CVE has no public exploit maturity and no attributed threat actors, so look for crash artifacts rather than a known implant. Search dmesg, journald (kernel facility), kdump/vmcore, and panic consoles for KASAN or oops stacks that include ip6_protocol_deliver_rcu together with seg6_local_input_core, lwtunnel_input, and ipv6_rthdr_rcv. Review netlink/rtnetlink and ip-monitor history for unexpected `encap seg6local` End.DT6 or End.DX6 SID installation, especially from unprivileged or container net namespaces. Packet captures or NetFlow toward local SIDs showing IPv6 routing-header type 4 combined with Hop-by-Hop and Destination Options immediately before an SRH are suspicious in environments that do not normally run SRv6. Correlate any such traffic with a subsequent kernel oops on the same host.

• KASAN: slab-out-of-bounds in ip6_protocol_deliver_rcu
• ip6_protocol_deliver_rcu+
• seg6_local_input_core+
• lwtunnel_input+
• ipv6_rthdr_rcv+
• seg6_local_input_core
• encap seg6local action End.DT6
• encap seg6local action End.DX6
• BUG: KASAN: slab-out-of-bounds

What your security team should do

• Prioritize kernel updates on any host that terminates SRv6 or allows local SID installation; treat as urgent despite low EPSS and non-KEV status because impact is kernel-wide
• Disable SRv6 local behaviors (End.DT6/End.DX6) and unprivileged user/net namespaces where they are not a required function
• Edge-filter IPv6 routing-header type 4 and unusual Hop-by-Hop/Destination Options stacks if SRv6 is unused
• Hunt kernel logs for the KASAN/oops signatures below and audit rtnetlink for unexpected seg6local SID adds
• Track distro stable kernels until the IP6CB-reset commit is confirmed present; re-image or isolate hosts that already oopsed in this path