CVE-2026-53184: Linux Kernel UDP Sockmap Denial-of-Service Vulnerability

Technical summary

The vulnerability stems from a union in the sk_buff structure where skb->dev (normally a network_device pointer) is repurposed as dev_scratch to cache truesize and state information during UDP receive processing. When a UDP socket is attached to a sockmap with an SK_SKB verdict program, the recv_actor (sk_psock_verdict_recv) callback executes in softirq context and may invoke BPF socket-lookup helpers (bpf_sk_lookup_tcp/udp, bpf_skc_lookup_tcp). These helpers check if skb->dev is non-NULL and attempt to call dev_net(skb->dev) to infer the network namespace. However, skb->dev still contains the dev_scratch value—an integer cast as a pointer—leading to a dereference of a non-canonical address. The rmem charge accounted via dev_scratch is released by skb_recv_udp() before recv_actor() runs, leaving the field poisoned. The fix clears skb->dev before sockmap verdict execution so that dev_net() checks fail gracefully and the lookup falls back to the correct sock_net(skb->sk) path.

Business impact

This vulnerability can cause kernel panics on systems running eBPF socket map programs on UDP sockets. For production environments relying on eBPF for networking policies, load balancing, or packet filtering, unexpected kernel crashes disrupt service availability and complicate incident response. The attack surface is limited to local actors with capability to load eBPF programs or processes inside containers with appropriate privileges, but the impact—a denial-of-service crash—is immediate and severe. Recovery requires either disabling the affected eBPF programs or upgrading the kernel.

Affected systems

The Linux kernel is affected across all versions that support sockmap and UDP socket integration with eBPF. The issue manifests when both UDP socket maps and SK_SKB verdict programs are active. Any Linux distribution or custom kernel shipping recent kernel versions with eBPF networking support is potentially vulnerable. Systems using kernel-based load balancers (e.g., Cilium, kube-proxy with eBPF acceleration) or intrusion detection via eBPF are at higher risk.

Exploitability

Exploitability requires local access and the ability to load eBPF programs or to control an application that uses sockmap-attached UDP sockets. In containerized environments, this is feasible within a container with appropriate capabilities. The crash is deterministic once the conditions are met (UDP receive on a sockmap-attached socket while an eBPF lookup helper executes), making it straightforward to trigger for an attacker who understands the setup. However, the vulnerability does not permit privilege escalation or information disclosure—it is purely a denial-of-service vector.

Remediation

Patch the kernel to versions that include the fix clearing skb->dev before sockmap verdict processing. Verify with your Linux distribution's security advisories for the exact patched version. Until patching is possible, operators can mitigate by disabling UDP socket maps or by removing/recompiling eBPF programs that use socket-lookup helpers on UDP sockets. Network segmentation to restrict eBPF program loading to trusted users reduces risk.

Patch guidance

Check your Linux distribution's advisory for CVE-2026-53184 to obtain the specific patched kernel version. The fix is typically a simple change to clear skb->dev at the entry point of sockmap verdict callbacks. Backports may be available for older stable kernel branches. Test patches in a non-production environment before rolling out, particularly if you rely on eBPF networking features.

Detection guidance

Monitor kernel logs (dmesg, journalctl) for general protection fault messages with 'non-canonical address' and stack traces involving bpf_skc_lookup or sk_psock_verdict_recv. These are hallmarks of this vulnerability being triggered. System monitoring tools that track kernel panic rates will flag affected hosts. On systems running eBPF socket programs, any unexpected increase in kernel crashes warrants investigation.

Why prioritize this

Although the CVSS score is 7.5 (HIGH), indicating significant severity, the actual risk to most organizations is moderated by the requirement for local access and eBPF program control. Prioritize patching for systems actively using eBPF socket maps (e.g., eBPF-based load balancers, service mesh data planes, container networking). Standard desktop or server workloads without eBPF are unaffected. However, for cloud-native and containerized deployments, this is a critical stability issue that warrants expedited patching.

Risk score, explained

The CVSS 3.1 score of 7.5 reflects high severity due to network availability impact (any network-facing UDP socket can be a vector in an eBPF-enabled kernel), low attack complexity, and no privilege escalation barrier within the local context. The score does not account for the practical constraint that triggering requires eBPF capability or control; in real-world risk models, organizations without eBPF workloads should lower their internal priority.

Frequently asked questions