CVE-2026-53184
WysokieCVSS 7.5Prawdopodobieństwo exploitacji (EPSS)
Niskie ryzykoPercentyl 40 — wyżej niż 40% wszystkich znanych CVE
Streszczenie
W jądrze Linux stwierdzono podatność w ścieżce odbioru UDP, gdzie pole skb->dev jest ponownie wykorzystywane jako dev_scratch (cache stanu). Gdy gniazdo UDP znajduje się w sockmap, program weryfikujący SK_SKB może wywołać pomocnika wyszukiwania gniazd (bpf_sk_lookup), który odczytuje skb->dev jako wskaźnik do struktury net_device, co prowadzi do dereferencji niekanonicznego adresu i błędu ogólnej ochrony (GPF) w kontekście softirq.
Ocena ryzyka
Atakujący może zdalnie spowodować awarię systemu (kernel panic) poprzez wysłanie specjalnie spreparowanego pakietu UDP do gniazda objętego mapą sockmap, co prowadzi do odmowy usługi (DoS).
Rekomendacja
Należy niezwłocznie zaktualizować jądro Linux do wersji zawierającej poprawkę, która czyści pole skb->dev przed uruchomieniem programu weryfikującego w sockmap.
Oryginalny opis (angielski, źródło NVD)
In the Linux kernel, the following vulnerability has been resolved: udp: clear skb->dev before running a sockmap verdict On the UDP receive path skb->dev is repurposed as dev_scratch (the truesize/state cache set by udp_set_dev_scratch()), through the union { struct net_device *dev; unsigned long dev_scratch; } in sk_buff. When a UDP socket is in a sockmap, sk_data_ready is sk_psock_verdict_data_ready(), which calls udp_read_skb() -> recv_actor() (sk_psock_verdict_recv) to run the attached SK_SKB verdict program in softirq. If that program calls a socket-lookup helper (bpf_sk_lookup_tcp/udp, bpf_skc_lookup_tcp), bpf_skc_lookup() does: if (skb->dev) caller_net = dev_net(skb->dev); skb->dev still holds the dev_scratch value (a non-NULL integer), so dev_net() dereferences it as a struct net_device * and the kernel takes a general protection fault on a non-canonical address in softirq: Oops: general protection fault, probably for non-canonical address 0x1010000800004a0 CPU: 1 UID: 0 PID: 1406 Comm: syz.2.19 Not tainted 7.1.0-rc6 #1 PREEMPT(full) RIP: 0010:bpf_skc_lookup net/core/filter.c:7033 [inline] RIP: 0010:bpf_sk_lookup+0x45/0x160 net/core/filter.c:7047 Call Trace: <IRQ> bpf_prog_4675cb904b7071f8+0x12e/0x14e bpf_prog_run_pin_on_cpu+0xc6/0x1f0 sk_psock_verdict_recv+0x1ba/0x350 udp_read_skb+0x31a/0x370 sk_psock_verdict_data_ready+0x2e3/0x600 __udp_enqueue_schedule_skb+0x4c8/0x650 udpv6_queue_rcv_one_skb+0x3ec/0x740 udp6_unicast_rcv_skb+0x11d/0x140 ip6_protocol_deliver_rcu+0x61e/0x950 ip6_input_finish+0xa9/0x150 NF_HOOK+0x286/0x2f0 ip6_input+0x117/0x220 NF_HOOK+0x286/0x2f0 __netif_receive_skb+0x85/0x200 process_backlog+0x374/0x9a0 __napi_poll+0x4f/0x1c0 net_rx_action+0x3b0/0x770 handle_softirqs+0x15a/0x460 do_softirq+0x57/0x80 </IRQ> The rmem charge that dev_scratch accounted for is released by skb_recv_udp() on dequeue, just above, so the scratch is dead by the time recv_actor() runs. Clear skb->dev so bpf_skc_lookup() falls back to sock_net(skb->sk), which skb_set_owner_sk_safe() set just above.