CVE-2026-80612

CRITICALPre-NVD 9.89.8
EchelonGraph scoreHIGH confidence

Score 9.8 from GitHub Security Advisory (severity: CRITICAL) published 2026-08-28. a secondary CVSS source baseline 9.8; sources differ by 0.0.

Triggered by: GitHub Security Advisory CVSS
Sources: epss, ghsa, secondary
Trending — 5 sources updated this week
9.8EG
EchelonGraph verdictPlan a fixSerious severity, but no confirmed exploitation yet.
  • High severity, but no confirmed exploitation yet
CISA-KEV: Not listedEPSS PROB: 0%CVSS: 9.8Exploit: None knownExposed: 0

No vendor fix yet — apply a workaround or compensating control (WAF / firewall / segmentation) and watch for a patch.

In the Linux kernel, the following vulnerability has been resolved:

net: lwtunnel: Drop skb metadata before LWT encapsulation

skb metadata is meant for passing information between XDP and TC. It lives in the skb headroom, immediately before skb->data. LWT programs cannot access the __sk_buff->data_meta pseudo-pointer to metadata.

However, LWT encapsulation prepends outer headers, moving skb->data back over the headroom where the metadata sits. On an RX-originated (forwarded) packet that still carries XDP metadata this goes wrong in two different ways, depending on the encap type:

  • Non-BPF LWT encaps (mpls, seg6, ioam6 ...) call skb_push()/skb_pull()
and silently overwrite the metadata that sits in the headroom.

2) BPF LWT xmit calls bpf_skb_change_head(), which uses skb_data_move(). That helper expects metadata immediately before skb->data. But since the IP output path runs LWT xmit before neighbour output has built the outgoing L2 header, for forwarded packets skb->data points at the L3 header while skb_mac_header() still points at the old L2 header. skb_data_move() sees metadata ending at skb_mac_header(), not before skb->data, warns and clears metadata:

WARNING: CPU: 21 PID: 454557 at include/linux/skbuff.h:4609 skb_data_move+0x47/0x90 CPU: 21 UID: 0 PID: 454557 Comm: napi/iconduit-g Tainted: G O 6.18.21 #1 RIP: 0010:skb_data_move+0x47/0x90 Call Trace: bpf_skb_change_head+0xe6/0x1a0 bpf_prog_...+0x213/0x2e3 run_lwt_bpf.isra.0+0x1d3/0x360 bpf_xmit+0x46/0xe0 lwtunnel_xmit+0xa1/0xf0 ip_finish_output2+0x1e7/0x5e0 ip_output+0x63/0x100 __netif_receive_skb_one_core+0x85/0xa0 process_backlog+0x9c/0x150 __napi_poll+0x2b/0x190 net_rx_action+0x40b/0x7f0 handle_softirqs+0xd2/0x270 do_softirq+0x3f/0x60

That is what happens, as for how to fix it - a received packet that carries metadata can reach an encap through any of the three LWT redirect modes:

LWTUNNEL_STATE_INPUT_REDIRECT ip6_rcv_finish dst_input lwtunnel_input

LWTUNNEL_STATE_OUTPUT_REDIRECT ip6_rcv_finish dst_input ip6_forward ip6_forward_finish dst_output lwtunnel_output

LWTUNNEL_STATE_XMIT_REDIRECT ip6_rcv_finish dst_input ip6_forward ip6_forward_finish dst_output ip6_output ip6_finish_output ip6_finish_output2 lwtunnel_xmit

Every encap funnels through the three LWT dispatch helpers, so drop the metadata there, right before handing the skb to the encap op. This single chokepoint covers all encap types and all three redirect modes:

  • lwtunnel_input(): seg6, rpl, ila, seg6_local
  • lwtunnel_output(): ioam6
  • lwtunnel_xmit(): mpls, LWT BPF xmit

Alternatively, we could clear the metadata right after TC ingress hook. That would require a compromise, however. Metadata would become inaccessible from TC egress (in setups where it actually reaches the hook it tact, that is without any L2 tunnels on path).

CVSS v3
9.8
EG Score
9.8(high)
EG Risk
49(Track)
EG Risk 49/100SSVC: Track

EG Risk is EchelonGraph's 0–100 priority score: it fuses intrinsic severity with real-world exploitation and automatability so you can rank equal-severity CVEs and fix the most dangerous first. Higher = act sooner. Distinct from the 0–10 EG Score (severity).

How it’s computed
Severity98% × 45%
Exploitation0% × 40%
Automatability30% × 15%
Action: Routine — remediate on your standard cadence.
EPSS PROB
0%
EPSS %ILE
31%
KEV
Not listed

Published

August 28, 2026

Last Modified

August 29, 2026

Advisory Details (2)

Auto-updated Aug 29, 2026
No patch confirmed yet.
generic

net: lwtunnel: Drop skb metadata before LWT encapsulation - kernel/git/stable/linux.git - Linux kernel stable tree

https://git.kernel.org/stable/c/c00320b0e355c4bf0ae4743a53b4180fea237546
generic

net: lwtunnel: Drop skb metadata before LWT encapsulation - kernel/git/stable/linux.git - Linux kernel stable tree

https://git.kernel.org/stable/c/19eec11f3ab5dd29ba58f5f209c24e946c95ef12

Vendor Advisories for CVE-2026-80612(1)

These vendors published their own advisory mentioning this CVE — often with vendor-specific remediation steps + affected product lists not in NVD.

Data Freshness Timeline

(refreshed 17× in last 7d / 17× in last 30d)

Each row is a source pipeline that fetched or updated this CVE on that date, with what changed. For example, "NVD update" means NVD published or revised its analysis for this CVE; "MITRE cvelistV5" means we ingested or refreshed it from the CNA feed. Most recent first.

  1. 2026-08-30 03:20 UTCEG score recompute
  2. 2026-08-30 03:20 UTCGHSA enrichment
  3. 2026-08-30 01:22 UTCEPSS rescore
  4. 2026-08-29 23:22 UTCGHSA enrichment
  5. 2026-08-29 19:24 UTCGHSA enrichment
  6. 2026-08-29 15:25 UTCGHSA enrichment
  7. 2026-08-29 11:27 UTCEG score recompute
  8. 2026-08-29 11:27 UTCGHSA enrichment
  9. 2026-08-29 07:27 UTCEG score recompute
  10. 2026-08-29 07:27 UTCGHSA enrichment
  11. 2026-08-29 06:37 UTCEG score recompute 9.80
  12. 2026-08-29 06:37 UTCGHSA enrichment
  13. 2026-08-29 06:33 UTCMITRE cvelistV5CVSS v3 → 9.8 · severity → CRITICAL
  14. 2026-08-28 21:42 UTCEPSS rescore
  15. 2026-08-28 08:20 UTCNVD update
  16. 2026-08-28 07:36 UTCEG score recompute
  17. 2026-08-28 07:32 UTCMITRE cvelistV5first tracked

Frequently asked(5)

What is CVE-2026-80612?
CVE-2026-80612 is a critical vulnerability published on August 28, 2026. In the Linux kernel, the following vulnerability has been resolved: net: lwtunnel: Drop skb metadata before LWT encapsulation skb metadata is meant for passing information between XDP and TC. It lives in the skb headroom, immediately before skb->data. LWT programs cannot access the skbuff->datameta…
When was CVE-2026-80612 disclosed?
CVE-2026-80612 was first published in the National Vulnerability Database on August 28, 2026, with the most recent update on August 29, 2026. EchelonGraph re-ingests CVE updates from NVD on a 2-hour cycle, so this page reflects the latest published state.
Is CVE-2026-80612 actively exploited?
CVE-2026-80612 is not currently on CISA's Known Exploited Vulnerabilities catalog. FIRST EPSS estimates a 0% probability of exploitation in the next 30 days, which ranks it in the top 69.2% of all scored CVEs.
What is the CVSS score of CVE-2026-80612?
CVE-2026-80612 has a CVSS v3 base score of 9.8 (NVD).
How do I remediate CVE-2026-80612?
Patch to the fixed version published by the affected vendor. Where vendor advisories exist for CVE-2026-80612, EchelonGraph cross-links them in the Vendor Advisories panel below — those typically contain the canonical remediation steps, fixed version numbers, and any vendor-specific mitigations.

Dependency Blast Radius

Explore the affected products and dependency analysis for CVE-2026-80612

Explore →

Is Your Infrastructure Affected by CVE-2026-80612?

EchelonGraph automatically scans your cloud infrastructure and maps CVE exposure using blast radius analysis.