Answer in brief
CVE-2026-53184 records a High severity (CVSS 7.5) vulnerability in udp: clear skb->dev before running a sockmap verdict. The current sources do not mark it as known exploited. The current feed maps Linux/Linux (generic), Linux/Linux (generic), Siemens/SIMATIC S7-1500 TM MFP - GNU/Linux subsystem (generic). Check affected ranges and fixed versions before updating.
Analysis pending evidence review
HOL Guard separates source facts from reviewed analysis. See the methodology.
CVSS is 7.5. The current sources do not mark it as known exploited. Treat this as a source-backed prioritization signal, not a statement about your environment.
Analysis status
Analysis pending evidence review
Factual feed record only; HOL analysis is not approved for indexing. Read the methodology.
The current feed maps Linux/Linux (generic), Linux/Linux (generic), Siemens/SIMATIC S7-1500 TM MFP - GNU/Linux subsystem (generic). Check affected ranges and fixed versions before updating.
| Product | Affected versions | Fixed versions |
|---|---|---|
| cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:* | Not reported | Not reported |
| cpe:2.3:o:linux:linux_kernel:7.1:rc1:*:*:*:*:*:* | Not reported | Not reported |
| cpe:2.3:o:linux:linux_kernel:7.1:rc2:*:*:*:*:*:* | Not reported | Not reported |
| cpe:2.3:o:linux:linux_kernel:7.1:rc3:*:*:*:*:*:* | Not reported | Not reported |
| cpe:2.3:o:linux:linux_kernel:7.1:rc4:*:*:*:*:*:* | Not reported | Not reported |
| cpe:2.3:o:linux:linux_kernel:7.1:rc5:*:*:*:*:*:* | Not reported | Not reported |
| cpe:2.3:o:linux:linux_kernel:7.1:rc6:*:*:*:*:*:* | Not reported | Not reported |
| Package | Affected range | Fixed version |
|---|---|---|
| Linux/Linuxgeneric | >=965b57b469a589d64d81b1688b38dcb537011bb0 <263779a6beff03b8b06f6d25566cb0f45af361f2 || >=965b57b469a589d64d81b1688b38dcb537011bb0 <1b585673a2249f13678e7ac443ac683ba767e0b6 || >=965b57b469a589d64d81b1688b38dcb537011bb0 <90d35188aaa92b8f8b23f66335e0e91bf60103a3 || >=965b57b469a589d64d81b1688b38dcb537011bb0 <6822eed69572000a181fa4e31fceacc60918c471 || >=965b57b469a589d64d81b1688b38dcb537011bb0 <7d6d92d000ebe3a845a17c165c1d3a70c5d84fe1 || >=965b57b469a589d64d81b1688b38dcb537011bb0 <3c94f241f776562c489876ff506f366224565c21 | 263779a6beff03b8b06f6d25566cb0f45af361f2, 1b585673a2249f13678e7ac443ac683ba767e0b6, 90d35188aaa92b8f8b23f66335e0e91bf60103a3, 6822eed69572000a181fa4e31fceacc60918c471, 7d6d92d000ebe3a845a17c165c1d3a70c5d84fe1, 3c94f241f776562c489876ff506f366224565c21 |
| Linux/Linuxgeneric | 6.0 | Not reported |
| Siemens/SIMATIC S7-1500 TM MFP - GNU/Linux subsystemgeneric | >=0 <* | * |
Published upstream
Jun 25, 2026
Evidence: source:cvelist:source_dates:source-dates:recordSource modified
Oct 19, 2026
Evidence: source:cvelist:source_dates:source-dates:recordFirst seen by HOL
Jun 25, 2026
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.
Quoted source text, attributed separately from HOL analysis.