Skip to main content
VulnerabilityPublished Updated

CVE-2026-53184: Linux kernel · udp: clear skb->dev before running a sockmap verdict

Affects Linux kernelSource CVE Database V5

0

Not known to be exploited · CVSS 7.5 High · fixed in 263779a6beff03b8b06f6d25566cb0f45af361f2 : patch Linux kernel soon.

Data as of 26 Oct 2026, 17:30 UTC

CVSS 3.1 base score
7.5High
How severe the flaw is on the 0–10 CVSS scale.
EPSS
0.4% chance of exploitation in 30 days – higher than 41% of CVEsExploit Prediction Scoring System: the likelihood attackers will use this flaw soon.
CISA SSVC
Exploitation
No evidence of active exploitation and no public proof of concept
Automatable
Attackers can reliably automate steps 1–4 of the kill chain
Technical impact
Limited control over the software or limited information exposure

CISA SSVC assessment, 2026-10-16.

Patch
Available – fixed in 263779a6beff03b8b06f6d25566cb0f45af361f2, 6822eed69572000a181fa4e31fceacc60918c471, 90d35188aaa92b8f8b23f66335e0e91bf60103a3 +3
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H

Exploitation evidence

  1. Disclosed: evidence found.

    CVE published 25 Jun 2026

  2. Detectable: no evidence on record.

    No public nuclei template indexed

  3. Weaponised: no evidence on record.

    No public exploit code indexed in Metasploit or Exploit-DB

  4. Exploited in the wild: no evidence on record.

    Not in CISA KEV and no source reports exploitation

  5. Observed by OffSeq Mirage: no evidence on record.

    No attack traffic recorded by OffSeq Mirage sensors

A missing step is not evidence of safety. Sources: cve.org (opens in a new tab), the Metasploit, Exploit-DB and nuclei-templates index as of 26 Oct 2026.

What to do

Upgrade to a fixed release listed under Affected software.

Affected software

ProductAffectedFixed in
LinuxLinuxAffected
  • ≥ 965b57b469a589d64d81b1688b38dcb537011bb0, < 263779a6beff03b8b06f6d25566cb0f45af361f2
Fixed in
  • 263779a6beff03b8b06f6d25566cb0f45af361f2
LinuxLinuxAffected
  • ≥ 965b57b469a589d64d81b1688b38dcb537011bb0, < 6822eed69572000a181fa4e31fceacc60918c471
Fixed in
  • 6822eed69572000a181fa4e31fceacc60918c471
LinuxLinuxAffected
  • ≥ 965b57b469a589d64d81b1688b38dcb537011bb0, < 90d35188aaa92b8f8b23f66335e0e91bf60103a3
Fixed in
  • 90d35188aaa92b8f8b23f66335e0e91bf60103a3
LinuxLinuxAffected
  • ≥ 965b57b469a589d64d81b1688b38dcb537011bb0, < 7d6d92d000ebe3a845a17c165c1d3a70c5d84fe1
Fixed in
  • 7d6d92d000ebe3a845a17c165c1d3a70c5d84fe1
LinuxLinuxAffected
  • ≥ 965b57b469a589d64d81b1688b38dcb537011bb0, < 3c94f241f776562c489876ff506f366224565c21
Fixed in
  • 3c94f241f776562c489876ff506f366224565c21
LinuxLinuxAffected
  • ≥ 965b57b469a589d64d81b1688b38dcb537011bb0, < 1b585673a2249f13678e7ac443ac683ba767e0b6
Fixed in
  • 1b585673a2249f13678e7ac443ac683ba767e0b6

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.

References

Community reviews

Loading reviews…