Answer in brief
CVE-2026-98096 records a High severity (CVSS 7.4) vulnerability in ipv6: sr: restore network header before routing and forwarding. The current sources do not mark it as known exploited. The current feed maps Linux/Linux (generic), Linux/Linux (generic). Check affected ranges and fixed versions before updating.
Analysis pending evidence review
HOL Guard separates source facts from reviewed analysis. See the methodology.
CVSS is 7.4. The current sources do not mark it as known exploited. Treat this as a source-backed prioritization signal, not a statement about your environment.
Analysis status
Analysis pending evidence review
Factual feed record only; HOL analysis is not approved for indexing. Read the methodology.
The current feed maps Linux/Linux (generic), Linux/Linux (generic). Check affected ranges and fixed versions before updating.
| Package | Affected range | Fixed version |
|---|---|---|
| Linux/Linuxgeneric | >=1ababeba4a21f3dba3da3523c670b207fb2feb62 <ce4c8beedc19aceeab0e7bdc6f34394fb158c47c || >=1ababeba4a21f3dba3da3523c670b207fb2feb62 <97b21ef57dfabbff660a4672c9fef7edfb720f47 || >=1ababeba4a21f3dba3da3523c670b207fb2feb62 <3ad7dca5e03bd64c65983a19734337512fd75491 || >=1ababeba4a21f3dba3da3523c670b207fb2feb62 <975b5b067f525a1b1338c4a3bee1c46545801518 | ce4c8beedc19aceeab0e7bdc6f34394fb158c47c, 97b21ef57dfabbff660a4672c9fef7edfb720f47, 3ad7dca5e03bd64c65983a19734337512fd75491, 975b5b067f525a1b1338c4a3bee1c46545801518 |
| Linux/Linuxgeneric | 4.10 | Not reported |
Published upstream
Sep 25, 2026
Evidence: source:cvelist:source_dates:source-dates:recordSource modified
Sep 25, 2026
Evidence: source:cvelist:source_dates:source-dates:recordFirst seen by HOL
Sep 25, 2026
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.
Quoted source text, attributed separately from HOL analysis.