CVE-2026-80840 in Linux
Summary
by MITRE • 09/04/2026
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.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.
Analysis
by VulDB Data Team • 09/04/2026
The Linux kernel contains a critical memory corruption vulnerability within the Segment Routing for IPv6 (seg6) implementation, specifically affecting the End.DX4 and End.DT4 packet processing actions. This flaw arises from improper handling of socket buffer control blocks during the decapsulation of encapsulated packets. When an IPv6 packet containing an inner IPv4 payload is processed by these functions, it undergoes decapsulation via the decap_and_validate function before being handed off directly to the IPv4 routing subsystem. Under normal circumstances, incoming IPv4 packets are routed through ip_rcv_core, which initializes and clears the IP control block (IPCB) stored in the socket buffer's control area. However, because this specific path bypasses that initialization step, the kernel retains stale data from the outer IPv6 header processing context.
The core technical flaw lies in the memory layout of the socket buffer control structures. Both the IPv4 IPCB and the IPv6 IP6CB utilize the same underlying storage space within skb->cb to save state information during packet processing. In little-endian architectures such as x86-64, specific fields from these two distinct headers overlap significantly. Specifically, the lastopt field in IP6CB overlaps with optlen and srr in IPCB, while nhoff in IP6CB overlaps with rr (Record Route) and ts (Timestamps) in IPCB. If an attacker constructs a malicious IPv6 packet with a valid outer extension header chain, they can manipulate these overlapping fields to inject arbitrary values into the IPv4 control block. For instance, by placing a Destination Options header immediately after the IPv6 header, an attacker can set the lastopt and nhoff fields to specific non-zero values that persist through decapsulation.
This manipulation leads directly to a slab-out-of-bounds write vulnerability when the kernel attempts to process TCP options for incoming connections. The tcp_v4_save_options function checks the optlen field in IPCB to determine if option data needs to be copied and allocated. Because the stale IP6CB lastopt value has overwritten optlen with a non-zero, attacker-controlled value such as forty bytes, the kernel proceeds to allocate memory for TCP options. Subsequently, __ip_options_echo is invoked to parse these options. Due to the overlapping nhoff field overwriting the rr (Record Route) length indicator in IPCB, this function reads an inner packet byte that has been set by the attacker to two hundred and fifty-five as the option length. Consequently, the kernel attempts to copy two hundred and fifty-five bytes of data into a buffer allocated for only forty bytes, resulting in a severe heap-based buffer overflow.
The operational impact of this vulnerability is significant, allowing remote attackers with network access to trigger arbitrary code execution or cause denial of service through kernel panic. The attack vector involves sending specially crafted IPv6 encapsulated packets that exploit the seg6 processing logic. The affected call paths include input_action_end_dx4_finish and input_action_end_dt4, which feed into standard TCP connection request handlers like tcp_v4_conn_request and ip_local_deliver. This means any Linux system acting as a router or endpoint supporting Segment Routing with IPv4 encapsulation is susceptible to this remote exploitation technique if it processes such traffic without the necessary kernel patches applied.
Mitigation for this vulnerability requires applying upstream kernel fixes that explicitly clear the IPv4 control block during the decapsulation process in the common path used by End.DX4, End.DT4, and End.DT46 operations. The fix involves saving the ingress interface index from IP6CB before clearing IPCB to ensure network interface context is preserved while preventing data leakage between protocol headers. It is crucial that implementations use IP6CB(skb)->iif rather than skb->skb_iif for this purpose, as l3mdev processing may alter the latter, whereas the former retains the accurate receiving interface set at IPv6 ingress. Administrators should ensure their systems are updated to kernel versions where decap_and_validate properly sanitizes control blocks before passing packets to higher-layer protocols.
From a classification perspective, this vulnerability aligns with CWE-120 Buffer Copy without Checking Size of Input and CWE-364 Signal Handler Race Condition in the context of memory corruption leading to execution flow hijacking. In terms of adversarial tactics, it corresponds to ATT&CK technique T1059 Command and Scripting Interpreter if exploitation leads to code execution, or more broadly to initial access vectors involving protocol manipulation. The flaw highlights the dangers of shared state structures across different network protocols without proper isolation boundaries during packet transformation operations.