Look up another CVE · open CVE-2026-98096 in the interactive tracker
CVE-2026-98096
ipv6: sr: restore network header before routing and forwarding
Published 2026-09-25 (24 days ago) by the Linux kernel CNA. Subsystem net/ipv6. Debian urgency: not yet assigned.
What to do, per Debian release
Debian's own status for CVE-2026-98096 in every release this site tracks, and what each one means in practice. Every status below is the one the Debian Security Team publishes for this CVE. source
| Release | Status | Version | What this means |
|---|---|---|---|
| Debian 12bookworm | fixedDLA-4841-1 · 2026-10-17 · text | 6.1.190-1 | Update the kernel and reboot. DLA-4841-1 shipped the fix on 2026-10-17, in 6.1.190-1. A running kernel keeps the old code until the machine restarts. |
| Debian 13trixie | fixedDSA-6528-1 · 2026-09-29 · text | 6.12.111-1 | Update the kernel and reboot. DSA-6528-1 shipped the fix on 2026-09-29, in 6.12.111-1. A running kernel keeps the old code until the machine restarts. |
| Debian 14forky | fixed | 7.2.7-1 | Update the kernel and reboot. Fixed in 7.2.7-1. A running kernel keeps the old code until the machine restarts. |
| Debian unstablesid | fixed | 7.2.7-1 | Update the kernel and reboot. Fixed in 7.2.7-1. A running kernel keeps the old code until the machine restarts. |
| Debian 12bookworm · linux-6.12 | fixedDLA-4817-1 · 2026-10-04 · text | 6.12.111-1~deb12u1 | Update the kernel and reboot. DLA-4817-1 shipped the fix on 2026-10-04, in 6.12.111-1~deb12u1. A running kernel keeps the old code until the machine restarts. |
The vulnerability
What the bug is
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.
Where it lives
The fix touches these files. If the subsystem is one you do not use, the practical exposure is lower, though the package is still the vulnerable one.
net/ipv6/exthdrs.c
- What this is
- NETWORKING [IPv4/IPv6]MAINTAINERS section matched on net/ipv6/exthdrs.c · netdev@vger.kernel.org · Maintained
Check it on the machine
grep -w CONFIG_IPV6 /boot/config-$(uname -r)Reads the booted kernel's own configuration, on the machine and nowhere else. =y is built in, =m is a module, and an is not set line means the code is not there.
Show whether Debian builds this, per release
Debian builds this code. Every release below compiles the affected file into the kernels it ships.
- bookworm, trixie, forky, sid, bookworm · linux-6.12y
- y
- built into the kernel image on every flavour - only a patch removes it
- Build switch
- CONFIG_IPV6
From the configuration Debian publishes for every kernel flavour it builds. It covers only the architectures Debian ships a linux-config package for, and nothing about a kernel you built yourself. Debian's own status above stays authoritative about the source package.MAINTAINERS kbuild Makefiles Debian linux-config packages
Signals
- Published
- 2026-09-25 (24 days ago)source
- CVSS
- 7.4 high
CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:H/A:Hsource recompute it - Attack vector
- network (AV:N)source
- EPSS
- 0.51%, higher than 42.3% of all CVEssource
- CISA KEV
- not listedthe KEV catalogue
- Debian urgency
- not yet assignedsource
- Subsystem
- net/ipv6
Upstream fixes
The versions the CNA records as introducing and fixing this, and the commit for each. source
| Introduced | Fixed in | Commit |
|---|---|---|
| 4.10 | 5.10.271 | f463c4786cf2 |
| 4.10 | 5.15.222 | 8f44d4160bcd |
| 4.10 | 6.1.189 | 9cfbe2c381ab |
| 4.10 | 6.6.158 | af08f62b5a5a |
| 4.10 | 6.12.111 | ce4c8beedc19 |
| 4.10 | 6.18.53 | 97b21ef57dfa |
| 4.10 | 7.2.7 | 3ad7dca5e03b |
| 4.10 | 7.3 | 975b5b067f52 |
Debian advisories
| Advisory | Date | Shipped to | Debian |
|---|---|---|---|
| DLA-4841-1 | 2026-10-17 | bookworm 6.1.190-1 | tracker |
| DLA-4817-1 | 2026-10-04 | bookworm 6.12.111-1~deb12u1 | tracker |
| DSA-6528-1 | 2026-09-29 | trixie 6.12.111-1 | tracker |
Why the CNA scored it this way
Quoted from the kernel CNA's own scoring file, word for word. A highlighted metric carries the most severe value CVSS v3.1 defines for it, which is what pushes the score up. source
- AV:NAttack vector, network
- The bad input is a routed IPv6 packet sent by a remote host: a Hop-by-Hop header followed by an SRH with segments_left>0. ipv6_srh_rcv() processes it on receive, and its fixed skb_push(sizeof(struct ipv6hdr)) leaves skb_network_offset() negative before ip6_route_input() and dst_input() forward the packet.
- AC:HAttack complexity, high
- ipv6_srh_rcv() drops the packet unless seg6_enabled, which defaults to 0, is set both in devconf_all and on the ingress interface. The out-of-bounds memcpy in sch_frag_prepare_frag() also needs the admin to have set up tc act_ct with an MRU plus act_mirred on the forwarding path. The remote attacker cannot set up either of these.
- PR:NPrivileges required, none
- No authentication is needed to send the packet. seg6_hmac_validate_skb() accepts SRHs that carry no HMAC TLV when seg6_require_hmac is at its default of 0, so an unauthenticated sender reaches the segments_left>0 branch.
- UI:NUser interaction, none
- No victim action is needed. The router processes the attacker's SRH packet in softirq receive context as soon as it arrives.
- S:UScope, unchanged
- The corruption stays inside the router's own kernel (skb metadata, then the per-CPU sch_frag_data_storage and memory after it). No VM, IOMMU or sandbox boundary is crossed.
- C:NConfidentiality impact, none
- With the negative offset, the flow dissector and the neighbour output path read or write inside the skb head, and the bytes sch_frag reads out of bounds go into per-CPU storage. I found no path that sends kernel memory back to the attacker.
- I:HIntegrity impact, high
- sch_frag_prepare_frag() takes the negative skb_network_offset() as unsigned hlen and runs memcpy(&data->l2_data, skb->data, hlen). That writes packet bytes the attacker supplied past the per-CPU sch_frag_data_storage buffer, an out-of-bounds kernel write.
- A:HAvailability impact, high
- The roughly 4 GB memcpy in sch_frag_prepare_frag() will fault and crash the router. On other paths the negative offset breaks flow dissection and garbles forwarded packets. The attacker can repeat this with each crafted packet.