Description

In the Linux kernel, the following vulnerability has been resolved: seg6: reset IP6CB after IPv6 decapsulation decap_and_validate() pulls the outer SRv6 headers and makes the inner packet the skb network header. The IPv6 control block still contains values collected while parsing the outer packet, including nhoff and extension-header flags. End.DX6 and End.DT6 route the inner IPv6 packet directly to the IPv6 input path. An unprivileged user can reach End.DT6 from a user and net namespace by installing a local SID and injecting an outer packet with Hop-by-Hop and Destination Options headers followed by an SRH and a minimal inner IPv6 packet. The outer extension headers leave a large nhoff in IP6CB. After decapsulation, ip6_protocol_deliver_rcu() uses that stale offset on the inner packet and reads beyond the skb head. KASAN reports: BUG: KASAN: slab-out-of-bounds in ip6_protocol_deliver_rcu ip6_protocol_deliver_rcu+0x1118/0x1450 ip6_input_finish+0x11b/0x240 seg6_local_input_core+0xed/0x2e0 lwtunnel_input+0x1e9/0x4e0 ipv6_rthdr_rcv+0x525f/0x6c50 ip6_protocol_deliver_rcu+0xcb7/0x1450 Before clearing IP6CB for an inner IPv6 packet, save its incoming interface index and L3 slave state. Restore both after the clear and set nhoff to the inner IPv6 base-header nexthdr field. Use IP6CB(skb)->iif rather than skb->skb_iif because VRF processing can replace skb_iif with the L3 master while IP6CB keeps the receiving interface. Preserve IP6SKB_L3SLAVE for the same reason.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "9.8",
  "pubDate": "2026-09-11T20:19:03.887Z",
  "pubdate": "2026-09-11T20:19:03.887Z",
  "executiveSummary": "A memory safety vulnerability exists in the Linux kernel's SRv6 (Segment Routing over IPv6) implementation, specifically within the decapsulation logic.\nThe vulnerability is identified as a slab-out-of-bounds read occurring during the transition of packet processing after decapsulation.\nThe flaw affects systems utilizing SRv6 End.DX6 or End.DT6 behaviors. It allows an attacker to trigger an out-of-bounds memory access, potentially leading to a kernel panic (denial of service) or information disclosure.\nExploitation can be achieved by an unprivileged user within a network namespace by injecting specially crafted IPv6 packets containing specific extension headers.\nThe root cause involves stale IPv6 control block (IP6CB) metadata persisting after outer header stripping, which leads to incorrect offset calculations when the inner packet is passed to the IPv6 input path.\nThis vulnerability highlights risks in complex network tunnel decapsulation processes where internal protocol metadata structures are improperly sanitized.",
  "technicalDetails": "The vulnerability resides within the `seg6` implementation of the Linux kernel, specifically during the `decap_and_validate()` routine. When an SRv6-encapsulated packet is processed, the kernel strips the outer SRv6 headers to expose the inner IPv6 packet. During this process, the kernel fails to properly reset the IPv6 control block (`IP6CB`).\nIP6CB contains critical metadata collected while parsing the outer packet, including `nhoff` (nexthdr offset) and various extension-header flags. In the context of `End.DX6` and `End.DT6` operations, the inner IPv6 packet is directly handed off to the standard IPv6 input path. If the outer packet contains complex extension headers (e.g., Hop-by-Hop or Destination Options headers), the `nhoff` value in `IP6CB` is left significantly larger than what is appropriate for the stripped, inner IPv6 header.\nThe attack flow begins when an unprivileged user, potentially within a constrained network namespace, installs a local SID. The user then transmits a crafted packet featuring an outer IPv6 header, multiple extension headers, an SRH (Segment Routing Header), and a minimal inner IPv6 packet. Upon reaching the SRv6 decapsulation point, the kernel strips the outer layers but preserves the corrupted `IP6CB` state.\nWhen the inner packet enters `ip6_protocol_deliver_rcu()`, the function relies on the stale `nhoff` value stored in `IP6CB`. Because this offset points beyond the actual boundaries of the newly exposed inner packet structure, the kernel attempts to read memory outside of the `skb` (socket buffer) head, triggering a slab-out-of-bounds error. KASAN (Kernel Address Sanitizer) intercepts this, confirming the violation and typically forcing a kernel crash.\nThe technical impact is twofold: local denial of service via kernel panic, and a potential side-channel for memory content disclosure if the out-of-bounds read is exploited to leak kernel data structures adjacent to the `skb`. The requirement to reset `IP6CB` while preserving specific state flags—such as `iif` (incoming interface index) and `IP6SKB_L3SLAVE`—is crucial, as these values are necessary for accurate routing and VRF-aware packet processing post-decapsulation."
}