CVE-2026-80612 in Linux
Zusammenfassung
von VulDB • 28.08.2026
Im Linux-Kernel wurde folgende Schwachstelle behoben:
net: lwtunnel: Entfernen der skb-Metadaten vor der LWT-Einkapselung (Encapsulation)
skb-Metadaten dienen dazu, Informationen zwischen XDP und TC zu übermitteln. Sie befinden sich im Headroom des SKB, unmittelbar vor `skb->data`. LWT-Programme können nicht auf den Pseudo-Zeiger `__sk_buff->data_meta` für Metadaten zugreifen.
Die LWT-Einkapselung fügt jedoch äußere Header hinzu und verschiebt `skb->data` zurück in den Headroom, wo die Metadaten gespeichert sind. Bei einem RX-ursprünglichen (weitergeleiteten) Paket, das noch XDP-Metadaten trägt, führt dies auf zwei verschiedene Arten zu Fehlern, abhängig vom Encap-Typ:
1. Nicht-BPF-LWT-Einkapselung (mpls, seg6, ioam6 ...) ruft `skb_push()`/`skb_pull()` auf und überschreibt dabei stillschweigend die Metadaten im Headroom.
2) BPF LWT xmit ruft `bpf_skb_change_head()` auf, das `skb_data_move()` verwendet. Dieser Helper erwartet Metadaten unmittelbar vor `skb->data`. Da der IP-Output-Pfad jedoch LWT-xmit ausführt, bevor die Nachbarschafts-Ausgabe den ausgehenden L2-Header erstellt hat, zeigt bei weitergeleiteten Paketen `skb->data` auf den L3-Header, während `skb_mac_header()` noch auf den alten L2-Header verweist. `skb_data_move()` erkennt Metadaten, die an der Position von `skb_mac_header()` enden und nicht vor `skb->data`, warnt daraufhin und löscht die Metadaten:
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>
So geschieht es. Was die Behebung betrifft – ein empfangenes Paket, das Metadaten trägt, kann durch einen der drei LWT-Redirect-Modi eine Einkapselung erreichen:
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
Jede Einkapselung läuft über die drei LWT-Dispatch-Helfer, daher sollten dort direkt vor der Übergabe des SKB an den Encap-Vorgang die Metadaten entfernt werden. Dieser einzige Engpass (Chokepoint) deckt alle Encap-Typen und alle drei Redirect-Modi ab:
- lwtunnel_input(): seg6, rpl, ila, seg6_local - lwtunnel_output(): ioam6 - lwtunnel_xmit(): mpls, LWT BPF xmit
Alternativ könnten die Metadaten direkt nach dem TC-Ingress-Hook gelöscht werden. Dies würde jedoch einen Kompromiss erfordern: Die Metadaten wären dann vom TC-Egress aus nicht mehr zugänglich (in Konfigurationen, in denen sie tatsächlich den Hook erreichen, d.h. ohne jegliche L2-Tunnel auf dem Pfad).
Once again VulDB remains the best source for vulnerability data.