CVE-2026-80612: net: lwtunnel: Drop skb metadata before LWT encapsulation
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:
1. 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:
<IRQ>
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
</IRQ>
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).
Security readout for executives and security teams
Plain-English summary
A Linux networking flaw can mishandle packet metadata when forwarded traffic enters Lightweight Tunnel encapsulation. The supplied record rates it critical, but the description demonstrates metadata overwrite or clearing and a kernel warning—not a confirmed path to complete system compromise. Exposure depends on specialized XDP, traffic-control, forwarding, and LWT configurations.
Executive priority
Treat as an urgent, configuration-dependent kernel update for Linux network infrastructure. First determine whether XDP metadata and LWT encapsulation coexist. Accelerate remediation where they do; use normal kernel maintenance priority elsewhere until vendors clarify affected branches and practical impact.
Technical view
RX-originated packets may retain XDP metadata in skb headroom. LWT encapsulation can prepend headers over that area, while BPF LWT xmit may invoke skb_data_move() with inconsistent data and MAC-header positions. Non-BPF encapsulations can overwrite metadata; BPF paths can warn and clear it. The referenced fix drops metadata in lwtunnel_input(), lwtunnel_output(), and lwtunnel_xmit() before encapsulation.
Likely exposure
Most exposed are Linux routers, gateways, or network appliances that forward RX traffic carrying XDP metadata into MPLS, SEG6, IOAM6, RPL, ILA, SEG6-local, or LWT BPF encapsulation. The supplied affected-version data is ambiguous; verify exact kernel branches and vendor backports rather than relying solely on its version list.
Exploitation context
The bundle reports CVSS 9.8 but does not establish exploitation in the wild, and KEV is false. No public exploit evidence is provided. Triggering appears to require a particular configured networking data path, although packets entering that path may be remotely supplied.
Researcher notes
The supplied CVSS claims complete confidentiality, integrity, and availability impact, but the technical narrative directly documents metadata overwrite, metadata clearing, and a warning only. The source bundle does not explain how those effects produce full compromise. Version entries are internally unclear, including commit identifiers and unusual ranges, so branch-level applicability requires confirmation from kernel or distribution advisories.
Mitigation direction
Install a vendor-supported kernel containing the referenced fix or its stable backport.
Prioritize routers, gateways, appliances, and hosts using XDP metadata with LWT encapsulation.
If patching is delayed, prevent XDP-metadata-bearing forwarded traffic from reaching affected LWT paths.
Consult distribution guidance for exact fixed package versions and reboot requirements.
Validation and detection
Inventory kernel versions and vendor package release identifiers on network-facing Linux systems.
Identify XDP, TC, forwarding, and LWT configurations using the named encapsulation types.
Confirm the installed kernel contains either referenced fix or an equivalent vendor backport.
Review kernel logs for skb_data_move warnings matching the supplied call trace.
Test affected forwarding paths in staging after updating, including BPF and non-BPF encapsulation.
Generated from the cited source records. This long-tail analysis has not been individually reviewed by a named human.
Potential ATT&CK relevance
Conservative CVE-to-ATT&CK context
These mappings and lookup hints may be relevant to the vulnerability behavior, CWE, affected product, or exposure path. Glexia-inferred context is not an official MITRE, ATT&CK, CWE, or CVE Program mapping.
ATT&CK lookup starting points
Use these exact CWE pages and searches to review the Glexia ATT&CK library from this CVE's weakness and description context.
cve · low confidence lookup
CVE-2026-80612 mapping review
Open the CVE-to-ATT&CK bridge for reviewed, inferred, or future official mappings tied to this CVE.
These fields come from the CVE record and ADP containers, not from Glexia's Take. They preserve time-varying source decisions such as CISA SSVC, KEV status, CVSS metrics, and provider references.
1CVSS vectors
3Timeline events
0ADP providers
3Source links
CVSS vector scores
1 official score
We collect every scored CVSS vector available in the official CNA and ADP containers. When more than one version is present, the table keeps the source vectors side by side instead of collapsing them into the highest score.