Cloudanix VulnDB

CVE-2026-80840

None

CVSS

—

EPSS

0.2%

Published

Sep 4, 2026

CISA due date

—

Cloudanix analysis

Next patch cycle SSVC: Track

A network packet handling error in the operating system kernel can let attackers crash servers or potentially take them over by sending specially crafted traffic.

Exploitation
Remote Unauthenticated
Attacker needs
None
Complexity
Moderate
Impact
Remote Code Execution
Component
OS kernel
Class
Buffer Overflow
Remediation
Patch
Effort
Medium
Patch risk
Low

What it actually does

Stale IP6CB data overlaps IPCB storage after SRv6 End.DX4/End.DT4 decapsulation, causing nonzero optlen and invalid rr values that trigger out-of-bounds write of 255 bytes in __ip_options_echo during TCP SYN option processing.

Why it matters to the business

Kernel crashes or potential remote code execution on Linux systems performing IPv6 segment routing with IPv4 decapsulation, risking service disruption and requiring urgent patching across server fleets.

How an attack unfolds

An attacker crafts an IPv6 packet containing a Destination Options header followed by a Segment Routing Header targeting End.DX4 or End.DT4 behavior; after decapsulation the retained IPv6 control block data causes IPv4 TCP path to miscalculate option lengths and perform an out-of-bounds memory write during connection setup.

How to fix it

Apply the upstream kernel patch that clears IPCB after decap_and_validate for IPIP and restores the ingress interface from IP6CB; rebuild and deploy updated kernel images to all affected systems.

How to confirm the fix worked

Confirm the fix by inspecting the decapsulation path for explicit IPCB clearing before IPv4 routing; re-test with the original reproducer packets and verify absence of KASAN reports or crashes.

Typical attack path

  1. Send crafted IPv6 packet with Destination Options and SRH to trigger SRv6 End.DX4/End.DT4
  2. Decapsulation bypasses ip_rcv_core leaving stale IP6CB values in shared skb->cb
  3. IPv4 TCP SYN processing calls tcp_v4_route_req and __ip_options_echo with optlen=40 and rr=40
  4. Function reads attacker-controlled byte as option length and copies 255 bytes into fixed 40-byte buffer
  5. Resulting slab-out-of-bounds write triggers KASAN or kernel panic

How to detect it

Search kernel logs for KASAN slab-out-of-bounds reports mentioning __ip_options_echo or tcp_v4_route_req following IPv6 decapsulation; inspect network traces for IPv6 packets containing Destination Options immediately before SRH targeting End.DX4/End.DT4.

What your security team should do

  • Prioritize kernel updates on any system exposing SRv6 End.DX4 or End.DT4 endpoints
  • Monitor for kernel oops or KASAN reports involving __ip_options_echo after IPv6 decapsulation
  • Restrict SRv6 usage to trusted sources until patched kernels are deployed

The record

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 decap_and_validate() and send it directly to IPv4 routing. The inner packet therefore bypasses ip_rcv_core(), 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. ipv6_destopt_rcv() 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 tcp_v4_save_options() and __ip_options_echo() 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 __ip_options_echo(). 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 __ip_options_echo() 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 __ip_options_echo() Write of size 255 The relevant End.DX4 call path is: __ip_options_echo tcp_v4_route_req tcp_conn_request tcp_v4_conn_request tcp_rcv_state_process tcp_v4_do_rcv tcp_v4_rcv ip_protocol_deliver_rcu ip_local_deliver_finish ip_local_deliver input_action_end_dx4_finish input_action_end_dx4 The relevant End.DT4 call path is: __ip_options_echo tcp_v4_route_req tcp_conn_request tcp_v4_conn_request tcp_rcv_state_process tcp_v4_do_rcv tcp_v4_rcv ip_protocol_deliver_rcu ip_local_deliver_finish ip_local_deliver input_action_end_dt4 tcp_v4_save_options() is inlined into the tcp_v4_route_req() path, so it does not appear as a separate frame. When decap_and_validate() handles IPPROTO_IPIP, 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->skb_iif. These actions run after l3mdev processing, which can replace skb_iif with the L3 master; IP6CB iif still records the receiving interface set at IPv6 ingress.

Affected packages

Ecosystem Package Introduced Fixed