CVE-2026-80612

*** 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-&gt;data. LWT programs cannot<br /> access the __sk_buff-&gt;data_meta pseudo-pointer to metadata.<br /> <br /> However, LWT encapsulation prepends outer headers, moving skb-&gt;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-&gt;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-&gt;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-&gt;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).