CVE-2026-80612
KrytyczneCVSS 9.8Prawdopodobieństwo exploitacji (EPSS)
Niskie ryzykoPercentyl 31 - wyżej niż 31% wszystkich znanych CVE
Streszczenie
W jądrze Linuxa odkryto podatność w mechanizmie LWT (Lightweight Tunnels). Podczas enkapsulacji tuneli LWT, metadane skb (przekazywane między XDP a TC) znajdujące się w headroom pakietu są nadpisywane lub usuwane, co prowadzi do ostrzeżeń i błędów w działaniu, szczególnie w przypadku pakietów przekazywanych dalej (forwarded) z metadanymi XDP. Problem dotyczy wszystkich typów enkapsulacji LWT (mpls, seg6, ioam6, BPF) i wszystkich trybów przekierowania LWT.
Ocena ryzyka
Podatność może powodować nieprawidłowe działanie przetwarzania pakietów, ostrzeżenia w logach jądra oraz potencjalne zakłócenia w działaniu tuneli LWT, co może wpłynąć na stabilność i bezpieczeństwo ruchu sieciowego w środowiskach korzystających z XDP/TC i enkapsulacji LWT.
Rekomendacja
Zaleca się jak najszybsze zastosowanie poprawki dostarczonej przez producenta jądra Linux, która usuwa metadane skb przed enkapsulacją LWT. Należy również monitorować logi jądra pod kątem ostrzeżeń skb_data_move i zaktualizować system do wersji jądra zawierającej poprawkę.
Inne podatności w Linux kernel
Zobacz wszystkie- CVE-2026-62840Wysokie
Warunek wyścigu typu time-of-check time-of-use (TOCTOU) w jądrze Linux umożliwia autoryzowanemu atakującemu lokalne podniesienie uprawnień.
- CVE-2026-98374Nieznane
W jądrze Linux występuje podatność use-after-free w tcp_send_synack() dotycząca retransmit_skb_hint. Gdy tcp_send_synack() zastępuje sklonowany SYN skb na początku kolejki retransmisji kopią, zwalnia oryginał, ale tp->retransmit_skb_hint nadal wskazuje na zwolniony obiekt, co może być wykorzystane przez nieuprzywilejowanego klienta TFO do wywołania use-after-free.
- CVE-2026-98373Nieznane
W jądrze Linux występuje błąd w move_hugetlb_page_tables(), gdzie adres docelowy jest przesuwany zbyt daleko, gdy offsety w tablicach stron źródłowej i docelowej różnią się. Może to prowadzić do paniki jądra na x86-64.
- CVE-2026-98048Nieznane
W jądrze Linux w podsystemie BPF funkcja mark_fastcall_pattern_for_call() musi zapewnić, że dopasowana sekwencja instrukcji "spill; call; fill" nie jest przerwana przez skok. W przeciwnym razie przepisanie zastosowane przez bpf_remove_fastcall_spills_fills() jest niepoprawne. Poprawka rejestruje instrukcje będące celami skoków w insn_aux_data[*].jump_target i używa tej flagi do zatrzymania rozwijania wzorca.
- CVE-2026-98047Nieznane
W jądrze Linux w podsystemie BPF funkcja in_rbtree_lock_required_cb() sprawdza tylko najgłębszą ramkę weryfikatora, przez co ograniczenia callbacku rbtree znikają w zagnieżdżonej ramce wywołania statycznego podprogramu. Podprogram może odblokować drzewo, usunąć i zwolnić porównywany węzeł, a następnie ponownie zablokować, co prowadzi do wstawienia zwolnionej pamięci do drzewa.
- CVE-2026-98045Nieznane
W jądrze Linux podatność w weryfikatorze BPF dotyczy helperów stosu, które mogą blokować na odczytach systemu plików (np. przy rozwiązywaniu build ID), ale nie były oznaczone jako uśpialne. Weryfikator mógł zezwolić na ich wywołanie z regionów nieuśpialnych, takich jak sekcje RCU czy z wyłączonym wywłaszczaniem.
- CVE-2026-98044Nieznane
W jądrze Linux weryfikator BPF błędnie obsługiwał przestarzałe instrukcje ładowania pakietów (BPF_LD_ABS/BPF_LD_IND) wywoływane z callbacków, co prowadziło do błędu weryfikatora i ostrzeżenia oraz błędu -EFAULT przy BPF_PROG_LOAD. Uprawniony ładowacz programów mógł wywołać ten problem.
- CVE-2026-98043Nieznane
W jądrze Linux weryfikator BPF błędnie wnioskował, że wskaźnik z nieograniczonym przesunięciem jest nie-NULL, opierając się tylko na typie. W wyniku tego program BPF mógł przejść weryfikację, a w czasie działania nastąpiło wyłuskanie wskaźnika NULL.
- CVE-2026-98042Nieznane
W jądrze Linux weryfikator BPF mógł przywrócić identyfikator skalara usunięty przez collect_linked_regs(), ponieważ kopie porównywanych rejestrów były wykonywane przed zebraniem powiązanych rejestrów. Mogło to prowadzić do niespójności zakresów i propagacji precyzji.
- CVE-2026-98041Wysokie
W jądrze Linux weryfikator BPF błędnie przewidywał wynik porównania wskaźnika z zerem w instrukcjach JMP32, nie odróżniając porównań BPF_JMP od BPF_JMP32. Prowadziło to do nieprawidłowego wnioskowania o zawsze wykonanym skoku.
Oryginalny opis (angielski, źródło NVD)
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).
Dane podatności pochodzą z NVD (NIST) · CISA KEV · EPSS

