ipv6: sr: restore network header before routing and forwarding
- Published
- Last modified
- Where the record stands: published, rejected by its publisher, or superseded by another id.What do these mean? →
- published
- Whether CISA lists it in its Known Exploited Vulnerabilities catalog: proof that attackers are using it.What do these mean? →
- Not listed in CISA KEV
- Fix
- Fixed in 5.10.271, 5.15.222, 6.1.189, 6.6.158, 6.12.111, and 2 more
- Whether working attack code is public (Exploit-DB, Metasploit, Nuclei or GitHub). Public code makes attacks easier.What do these mean? →
- None on Exploit-DB, Metasploit or GitHub
Summary
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.
Timeline
- CVE published
- Record last updated
Affected versions
- Linux Linux
From 1ababeba4a21f3dba3da3523c670b207fb2feb62 · fixed in f463c4786cf27376de7dfc0833a12e924a98f698; From 1ababeba4a21f3dba3da3523c670b207fb2feb62 · fixed in 8f44d4160bcdb3136a9145a4b9c7816382976925; From 1ababeba4a21f3dba3da3523c670b207fb2feb62 · fixed in 9cfbe2c381ab6d00a08e7a5b6028865adfb4e1bc; From 1ababeba4a21f3dba3da3523c670b207fb2feb62 · fixed in af08f62b5a5a446d6134a92d86771d3d12e0e3da; From 1ababeba4a21f3dba3da3523c670b207fb2feb62 · fixed in ce4c8beedc19aceeab0e7bdc6f34394fb158c47c; From 1ababeba4a21f3dba3da3523c670b207fb2feb62 · fixed in 97b21ef57dfabbff660a4672c9fef7edfb720f47; From 1ababeba4a21f3dba3da3523c670b207fb2feb62 · fixed in 3ad7dca5e03bd64c65983a19734337512fd75491; From 1ababeba4a21f3dba3da3523c670b207fb2feb62 · fixed in 975b5b067f525a1b1338c4a3bee1c46545801518
- Linux Linux
4.10
- KernelLinux
From 4.10.0 · fixed in 5.10.271; From 5.11.0 · fixed in 5.15.222; From 5.16.0 · fixed in 6.1.189; From 6.2.0 · fixed in 6.6.158; From 6.7.0 · fixed in 6.12.111; From 6.13.0 · fixed in 6.18.53; From 6.19.0 · fixed in 7.2.7
References 8
git.kernel.org
- stable/c/f463c4786cf27376de7dfc0833a12e924a98f698
- stable/c/8f44d4160bcdb3136a9145a4b9c7816382976925
- stable/c/9cfbe2c381ab6d00a08e7a5b6028865adfb4e1bc
- stable/c/af08f62b5a5a446d6134a92d86771d3d12e0e3da
- stable/c/ce4c8beedc19aceeab0e7bdc6f34394fb158c47c
- stable/c/97b21ef57dfabbff660a4672c9fef7edfb720f47
- stable/c/3ad7dca5e03bd64c65983a19734337512fd75491
- stable/c/975b5b067f525a1b1338c4a3bee1c46545801518