CVE-2026-80612
Fecha de publicación:
28/08/2026
*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br />
<br />
net: lwtunnel: Drop skb metadata before LWT encapsulation<br />
<br />
skb metadata is meant for passing information between XDP and TC. It lives<br />
in the skb headroom, immediately before skb->data. LWT programs cannot<br />
access the __sk_buff->data_meta pseudo-pointer to metadata.<br />
<br />
However, LWT encapsulation prepends outer headers, moving skb->data back<br />
over the headroom where the metadata sits. On an RX-originated (forwarded)<br />
packet that still carries XDP metadata this goes wrong in two different<br />
ways, depending on the encap type:<br />
<br />
1. Non-BPF LWT encaps (mpls, seg6, ioam6 ...) call skb_push()/skb_pull()<br />
and silently overwrite the metadata that sits in the headroom.<br />
<br />
2) BPF LWT xmit calls bpf_skb_change_head(), which uses skb_data_move().<br />
That helper expects metadata immediately before skb->data. But since<br />
the IP output path runs LWT xmit before neighbour output has built<br />
the outgoing L2 header, for forwarded packets skb->data points at the<br />
L3 header while skb_mac_header() still points at the old L2 header.<br />
skb_data_move() sees metadata ending at skb_mac_header(), not before<br />
skb->data, warns and clears metadata:<br />
<br />
WARNING: CPU: 21 PID: 454557 at include/linux/skbuff.h:4609 skb_data_move+0x47/0x90<br />
CPU: 21 UID: 0 PID: 454557 Comm: napi/iconduit-g Tainted: G O 6.18.21 #1<br />
RIP: 0010:skb_data_move+0x47/0x90<br />
Call Trace:<br />
<br />
bpf_skb_change_head+0xe6/0x1a0<br />
bpf_prog_...+0x213/0x2e3<br />
run_lwt_bpf.isra.0+0x1d3/0x360<br />
bpf_xmit+0x46/0xe0<br />
lwtunnel_xmit+0xa1/0xf0<br />
ip_finish_output2+0x1e7/0x5e0<br />
ip_output+0x63/0x100<br />
__netif_receive_skb_one_core+0x85/0xa0<br />
process_backlog+0x9c/0x150<br />
__napi_poll+0x2b/0x190<br />
net_rx_action+0x40b/0x7f0<br />
handle_softirqs+0xd2/0x270<br />
do_softirq+0x3f/0x60<br />
<br />
<br />
That is what happens, as for how to fix it - a received packet that<br />
carries metadata can reach an encap through any of the three LWT<br />
redirect modes:<br />
<br />
LWTUNNEL_STATE_INPUT_REDIRECT<br />
ip6_rcv_finish<br />
dst_input<br />
lwtunnel_input<br />
<br />
LWTUNNEL_STATE_OUTPUT_REDIRECT<br />
ip6_rcv_finish<br />
dst_input<br />
ip6_forward<br />
ip6_forward_finish<br />
dst_output<br />
lwtunnel_output<br />
<br />
LWTUNNEL_STATE_XMIT_REDIRECT<br />
ip6_rcv_finish<br />
dst_input<br />
ip6_forward<br />
ip6_forward_finish<br />
dst_output<br />
ip6_output<br />
ip6_finish_output<br />
ip6_finish_output2<br />
lwtunnel_xmit<br />
<br />
Every encap funnels through the three LWT dispatch helpers, so drop the<br />
metadata there, right before handing the skb to the encap op. This<br />
single chokepoint covers all encap types and all three redirect modes:<br />
<br />
- lwtunnel_input(): seg6, rpl, ila, seg6_local<br />
- lwtunnel_output(): ioam6<br />
- lwtunnel_xmit(): mpls, LWT BPF xmit<br />
<br />
Alternatively, we could clear the metadata right after TC ingress hook.<br />
That would require a compromise, however. Metadata would become<br />
inaccessible from TC egress (in setups where it actually reaches the<br />
hook it tact, that is without any L2 tunnels on path).
Gravedad: Pendiente de análisis
Última modificación:
28/08/2026