CVE-2026-80612

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->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 skbpush()/skbpull()

   and silently overwrite the metadata that sits in the headroom.

1. BPF LWT xmit calls bpfskbchangehead(), which uses skbdata_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 skbmacheader() still points at the old L2 header.

   skbdatamove() sees metadata ending at skbmacheader(), not before

   skb->data, warns and clears metadata:

  WARNING: CPU: 21 PID: 454557 at include/linux/skbuff.h:4609 skbdatamove+0x47/0x90

  CPU: 21 UID: 0 PID: 454557 Comm: napi/iconduit-g Tainted: G           O        6.18.21 #1

  RIP: 0010:skbdatamove+0x47/0x90

  Call Trace:

   <IRQ>

   bpfskbchange_head+0xe6/0x1a0

   bpfprog...+0x213/0x2e3

   runlwtbpf.isra.0+0x1d3/0x360

   bpf_xmit+0x46/0xe0

   lwtunnel_xmit+0xa1/0xf0

   ipfinishoutput2+0x1e7/0x5e0

   ip_output+0x63/0x100

   _netifreceiveskbone_core+0x85/0xa0

   process_backlog+0x9c/0x150

   _napipoll+0x2b/0x190

   netrxaction+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:

  LWTUNNELSTATEINPUT_REDIRECT

   ip6rcvfinish

     dst_input

       lwtunnel_input

  LWTUNNELSTATEOUTPUT_REDIRECT

   ip6rcvfinish

     dst_input

       ip6_forward

         ip6forwardfinish

           dst_output

             lwtunnel_output

  LWTUNNELSTATEXMIT_REDIRECT

   ip6rcvfinish

     dst_input

       ip6_forward

         ip6forwardfinish

           dst_output

             ip6_output

               ip6finishoutput

                 ip6finishoutput2

                   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:

• lwtunnelinput():  seg6, rpl, ila, seg6local
• 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).