CVE-2026-80840: ipv6: seg6: clear IPv4 control block on IPIP decapsulation

Published Sep 4, 2026
·
Updated

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

1 affected component
Linux Kernel=v7.2-rc5

Remediation

Recommended actions to resolve this vulnerability, in priority order.

  1. Upgrade

    Upgrade to a fixed release to a version that resolves this vulnerability.

    Fixed in v7.2-rc5

Event History

Sep 4, 2026
CVE Published
via MITRE·03:54 PM
Data Sourced
via MITRE·03:54 PM
Description

Frequently Asked Questions

1

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.

2

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.

Contact

SecAlerts Pty Ltd.
132 Wickham Terrace
Fortitude Valley,
QLD 4006, Australia
info@secalerts.co
By using SecAlerts services, you agree to our services end-user license agreement. This website is safeguarded by reCAPTCHA and governed by the Google Privacy Policy and Terms of Service. All names, logos, and brands of products are owned by their respective owners, and any usage of these names, logos, and brands for identification purposes only does not imply endorsement. If you possess any content that requires removal, please get in touch with us.
© 2026 SecAlerts Pty Ltd.
ABN: 70 645 966 203, ACN: 645 966 203