CVE-2026-80840: ipv6: seg6: clear IPv4 control block on IPIP decapsulation
In the Linux kernel, the following vulnerability has been resolved:
ipv6: seg6: clear IPv4 control block on IPIP decapsulation
End.DX4 and End.DT4 decapsulate an IPv4 packet through decapandvalidate() and send it directly to IPv4 routing. The inner packet therefore bypasses iprcvcore(), which normally clears IPCB before IPv4 interprets skb->cb.
The skb instead retains IP6CB data from the outer packet. IP6CB and IPCB use the same skb->cb storage, so IP6CB(skb)->lastopt overlaps IPCB(skb)->opt.optlen and srr, while IP6CB(skb)->nhoff overlaps rr and ts.
The sender can make the stale optlen byte nonzero with a valid outer extension-header chain. The reproducers put an eight-byte Destination Options header immediately after the 40-byte IPv6 header and before the Segment Routing Header. ipv6destoptrcv() records the sender-controlled Destination Options offset in both lastopt and nhoff, setting them to 40. On the reproduced little-endian x86-64 kernel, IPv4 therefore sees optlen = 40 and rr = 40.
Both tcpv4saveoptions() and ipoptionsecho() skip option copying when optlen is zero. Here optlen is 40, so the TCP SYN path allocates room for 40 bytes of option data and calls ipoptionsecho(). The stale rr value makes that function read inner packet byte 41 as the Record Route option length. The reproducers set that sender-controlled byte to 255, so ipoptionsecho() copies 255 bytes into the 40-byte option-data area.
Separate End.DX4 and End.DT4 reproducers on the unpatched v7.2-rc5 kernel both produced:
BUG: KASAN: slab-out-of-bounds in ipoptionsecho() Write of size 255
The relevant End.DX4 call path is:
ipoptionsecho tcpv4routereq tcpconnrequest tcpv4connrequest tcprcvstateprocess tcpv4dorcv tcpv4rcv ipprotocoldeliverrcu iplocaldeliverfinish iplocaldeliver inputactionenddx4finish inputactionenddx4
The relevant End.DT4 call path is:
ipoptionsecho tcpv4routereq tcpconnrequest tcpv4connrequest tcprcvstateprocess tcpv4dorcv tcpv4rcv ipprotocoldeliverrcu iplocaldeliverfinish iplocaldeliver inputactionenddt4
tcpv4saveoptions() is inlined into the tcpv4routereq() path, so it does not appear as a separate frame.
When decapandvalidate() handles IPPROTOIPIP, save the ingress interface from IP6CB, clear IPCB, and restore the saved value. Doing this in the common decapsulation path covers End.DX4, End.DT4, and End.DT46's IPv4 arm.
Use IP6CB(skb)->iif rather than skb->skbiif. These actions run after l3mdev processing, which can replace skbiif with the L3 master; IP6CB iif still records the receiving interface set at IPv6 ingress.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade to a fixed release to a version that resolves this vulnerability.
Fixed in v7.2-rc5
Event History
Frequently Asked Questions
Which systems are exposed to this issue?
Systems using the Linux kernel's SRv6 End.DX4 or End.DT4 behaviors are exposed when they decapsulate IPv4 packets and route the inner packet directly through IPv4. The affected path bypasses the normal IPv4 receive processing that clears the IPv4 control block.
What packet characteristics are needed to trigger the stale control-block state?
The sender must provide an outer IPv6 packet with a valid extension-header chain that causes a nonzero Destination Options offset to be recorded before the Segment Routing Header. The described reproducer uses an eight-byte Destination Options header immediately after the IPv6 header, causing IPv4 to interpret retained IPv6 control-block values as IPv4 option state.