GHSA-MH5Q-5QHG-XGRV
Vulnerability from github – Published: 2026-09-11 21:31 – Updated: 2026-09-14 15:32In 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.
{
"affected": [],
"aliases": [
"CVE-2026-80976"
],
"database_specific": {
"cwe_ids": [],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-09-11T20:19:03Z",
"severity": "CRITICAL"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nseg6: reset IP6CB after IPv6 decapsulation\n\ndecap_and_validate() pulls the outer SRv6 headers and makes the inner\npacket the skb network header. The IPv6 control block still contains\nvalues collected while parsing the outer packet, including nhoff and\nextension-header flags.\n\nEnd.DX6 and End.DT6 route the inner IPv6 packet directly to the IPv6\ninput path. An unprivileged user can reach End.DT6 from a user and net\nnamespace by installing a local SID and injecting an outer packet with\nHop-by-Hop and Destination Options headers followed by an SRH and a\nminimal inner IPv6 packet.\n\nThe outer extension headers leave a large nhoff in IP6CB. After\ndecapsulation, ip6_protocol_deliver_rcu() uses that stale offset on the\ninner packet and reads beyond the skb head. KASAN reports:\n\n BUG: KASAN: slab-out-of-bounds in ip6_protocol_deliver_rcu\n ip6_protocol_deliver_rcu+0x1118/0x1450\n ip6_input_finish+0x11b/0x240\n seg6_local_input_core+0xed/0x2e0\n lwtunnel_input+0x1e9/0x4e0\n ipv6_rthdr_rcv+0x525f/0x6c50\n ip6_protocol_deliver_rcu+0xcb7/0x1450\n\nBefore clearing IP6CB for an inner IPv6 packet, save its incoming\ninterface index and L3 slave state. Restore both after the clear and set\nnhoff to the inner IPv6 base-header nexthdr field.\n\nUse IP6CB(skb)-\u003eiif rather than skb-\u003eskb_iif because VRF processing can\nreplace skb_iif with the L3 master while IP6CB keeps the receiving\ninterface. Preserve IP6SKB_L3SLAVE for the same reason.",
"id": "GHSA-mh5q-5qhg-xgrv",
"modified": "2026-09-14T15:32:21Z",
"published": "2026-09-11T21:31:22Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-80976"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/2b154e96fcb3f01fd42765c64e0a56820fbc16eb"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/96c74420ac92930a7e0f21770818544eee4a93d7"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/9ae92198c24d7dacd4070e2f34f6e1ed3a63061c"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/a0e2b0a3718f0cf9fb0ee41710b4a6348a7315c8"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/c73fb911e02b9a766c950bc9707f3e3a96ffd702"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/cfa186a0857a0f831dfca67b16bbc40ecfdf3280"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/d1f0d353358987ca87f21d8956e2d2854951130d"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/f967455fb2a5a2079b9eb5823e9ccf359174bf9f"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
]
}
Drag nodes to arrange them. Double-click a related vulnerability to open it, or a source to visit its link. The Physics button on the left tunes the layout and the simulation; the legend at the bottom left hides or shows nodes by kind and by sighting type.
Sightings
| Author | Source | Type | Date | Other |
|---|
Nomenclature
- Seen: The vulnerability was mentioned, discussed, or observed by the user.
- Confirmed: The vulnerability has been validated from an analyst's perspective.
- Published Proof of Concept: A public proof of concept is available for this vulnerability.
- Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
- Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
- Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
- Not confirmed: The user expressed doubt about the validity of the vulnerability.
- Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.
Vulnerability timeline
Sightings and recorded dates, grouped by day · UTC
How durations are calculated
Following the VTEM framework (Black Hat USA 2015), time to patch starts when the vendor or a coordinator was informed, total time to patch at discovery, and disclosure to patch at public disclosure; vendor response time runs from the report to its acknowledgement. Time to exploit and time unpatched start at the earliest discovery or report, falling back to public disclosure. Unpatched time ends at the first recorded patch, or the calculation time when no patch is recorded. Exploitation to patch shows the interval between those two events; a published proof of concept is a public exploit, not exploitation.
Each result shows its source dates. A negative interval means the end event came first; when date-only inputs leave the order open, the result says so. Date-only inputs are approximate. The earliest evidence wins: KEV report dates and sightings are labelled as such. Records describing another vulnerability are listed but never calculated from, and a PoC alone does not establish exploitation. Missing patch evidence does not prove that no patch exists. Filters below change the event list only.
Loading timeline…
The approach is described in our paper Mapping CVEs to MITRE ATT&CK Techniques: A Curated Gold-Set Classifier and the Limits of LLM-Assisted Label Expansion.
Browse all ATT&CK techniques and the vulnerabilities related to each.
Related by attack behaviour
Vulnerabilities whose description is nearest to this one in the vector space of the CIRCL/vulnerability-attack-technique-biencoder model. This is a similarity search over the bi-encoder space (plain cosine), not a classification, and it has no measured accuracy.