CVE-2026-53184
Analyzed Analyzed - Analysis Complete

Kernel Oops in Linux UDP Sockmap due to skb->dev misuse

Vulnerability report for CVE-2026-53184, including description, CVSS score, EPSS score, affected products, exploitability, helpful resources, and attack-flow context.

Publication date: 2026-06-25

Last updated on: 2026-07-06

Assigner: kernel.org

Description

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.

CVSS Scores

EPSS Scores

Probability:
Percentile:

Meta Information

Published
2026-06-25
Last Modified
2026-07-06
Generated
2026-07-15
AI Q&A
2026-06-25
EPSS Evaluated
2026-07-14
NVD
EUVD

Affected Vendors & Products

Showing 11 associated CPEs
Vendor Product Version / Range
linux linux_kernel 7.1
linux linux_kernel 7.1
linux linux_kernel 7.1
linux linux_kernel 7.1
linux linux_kernel From 6.2 (inc) to 6.6.143 (exc)
linux linux_kernel From 6.0 (inc) to 6.1.176 (exc)
linux linux_kernel From 6.13 (inc) to 6.18.36 (exc)
linux linux_kernel From 6.7 (inc) to 6.12.94 (exc)
linux linux_kernel From 6.19 (inc) to 7.0.13 (exc)
linux linux_kernel 7.1
linux linux_kernel 7.1

Helpful Resources

Exploitability

CWE
CWE Icon
KEV
KEV Icon
CWE ID Description
CWE-UNKNOWN

Attack-Flow Graph

AI Quick Actions

Instant insights powered by AI
Executive Summary

This vulnerability exists in the Linux kernel's UDP receive path where the skb->dev field is repurposed as dev_scratch, a cache used internally. When a UDP socket uses a sockmap and runs a SK_SKB verdict program, if that program calls certain socket-lookup helpers, the kernel incorrectly dereferences skb->dev, which still holds the dev_scratch value instead of a valid network device pointer. This leads to a general protection fault due to dereferencing a non-canonical address in a softirq context.

The root cause is that skb->dev is not cleared before running the sockmap verdict, causing the kernel to treat an integer dev_scratch value as a pointer, resulting in a crash.

Impact Analysis

This vulnerability can cause the Linux kernel to crash with a general protection fault when processing UDP packets on sockets using sockmap with attached SK_SKB verdict programs. This can lead to denial of service (DoS) conditions as the kernel encounters fatal errors during packet processing.

Chat Assistant

Ask questions about this CVE
Hi! I’m here to help you understand CVE-2026-53184. Ask me anything about the vulnerability, its impact, or mitigation strategies.
0/70

EPSS Chart