KernelScan.io

HIGH Introduced in 4.10

ipv6 SRH Overflow

CVE-2026-98096

CVSS 7.4 / 10.0 NVD

CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:H/A:H

KernelScan AI9.8CRITICAL

01

In the Linux kernel, the following vulnerability has been resolved: ipv6: sr: restore network header before routing and forwarding ipv6_srh_rcv() runs with skb->data at the Segment Routing Header (SRH) while skb_network_header() points at the IPv6 header. When segments_left > 0, ipv6_srh_rcv() previously restored the skb->data position by pushing sizeof(struct ipv6hdr), assuming the SRH immediately followed the fixed IPv6 header. If another extension header (such as a Hop-by-Hop options header) precedes the SRH, skb_network_offset() remained negative. This led to two problems: 1. During ip6_route_input(), fib6_rules_early_flow_dissect() invokes __skb_flow_dissect() which passes the negative skb_network_offset() to flow dissection, breaking BPF and C flow dissector logic. 2. If forwarded via ip6_forward() or redirected via act_mirred, downstream handlers (like sch_fragment() or neighbour output) pass the negative offset as an unsigned length, triggering OOB memcpy or buffer overflows. Fix this by pushing -skb_network_offset(skb) before routing, ensuring skb_network_offset(skb) is 0 for route lookup / flow dissection as well as downstream forwarding. On the loopback path, pull skb_transport_offset(skb) to restore skb->data to the SRH before looping back.

02

Engine v0.6.0

Risk summary

A remote attacker can send a crafted IPv6 packet with a Segment Routing Header preceded by an extension header to trigger out-of-bounds memory writes in the kernel, potentially leading to code execution or a kernel crash. The target host must have IPv6 segment routing enabled (seg6_enabled sysctl set to 1).

Affectednet/ipv6/exthdrs.c (ipv6 sr)

Vulnerability analysis

When a Segment Routing Header in an IPv6 packet is preceded by another extension header (such as Hop-by-Hop options), the kernel's SRH processing code incorrectly restored the packet data position by assuming the routing header always immediately follows the fixed IPv6 header. This left the network header offset negative, which downstream forwarding and fragmentation handlers then interpreted as a very large unsigned length, causing out-of-bounds memory writes. The fix restores the data pointer to the correct network header position regardless of any intervening extension headers, and uses the transport offset on the loopback path. An attacker can trigger this by sending a crafted IPv6 packet to a host that has segment routing enabled, requiring no privileges beyond network reachability.

03

BranchIntroducedFixed inPatch commit
6.124.106.12.111ce4c8beedc19
6.184.106.18.5397b21ef57dfa
7.24.107.2.73ad7dca5e03b
mainline4.107.3-rc2975b5b067f52