CVE-2026-53184 Overview
CVE-2026-53184 is a Linux kernel vulnerability in the UDP receive path involving sockmap verdict programs. On the UDP receive path, skb->dev is repurposed as dev_scratch to cache truesize and state via the union defined in sk_buff. When a UDP socket is attached to a sockmap and the verdict program calls socket-lookup helpers such as bpf_sk_lookup_tcp, bpf_sk_lookup_udp, or bpf_skc_lookup_tcp, the helper dereferences the stale scratch value as a struct net_device * pointer. This triggers a general protection fault on a non-canonical address inside softirq context, causing a kernel crash.
Critical Impact
Local unprivileged users can trigger a kernel general protection fault (denial of service) by attaching an eBPF verdict program to a sockmap-enrolled UDP socket and invoking socket-lookup helpers.
Affected Products
- Linux kernel UDP stack (net/ipv4/udp.c, net/ipv6/udp.c)
- Linux kernel sockmap/sk_psock subsystem (net/core/skmsg.c)
- Linux kernel BPF socket lookup helpers in net/core/filter.c
Discovery Timeline
- 2026-06-25 - CVE-2026-53184 published to NVD
- 2026-06-25 - Last updated in NVD database
Technical Details for CVE-2026-53184
Vulnerability Analysis
The vulnerability is a [CWE-476] null/invalid pointer dereference triggered through field aliasing in sk_buff. The sk_buff structure defines a union between struct net_device *dev and unsigned long dev_scratch. On the UDP receive path, udp_set_dev_scratch() overwrites this field with a packed truesize and state value used for memory accounting.
When a UDP socket is enrolled in a sockmap, sk_data_ready is replaced by sk_psock_verdict_data_ready(). This handler calls udp_read_skb() which dispatches to recv_actor() (sk_psock_verdict_recv) to execute the attached SK_SKB verdict program inside softirq context. The rmem charge accounted by dev_scratch has already been released by skb_recv_udp() on dequeue, but the scratch value remains in skb->dev.
If the verdict program invokes a socket-lookup helper, bpf_skc_lookup() executes the check if (skb->dev) caller_net = dev_net(skb->dev);. The non-NULL integer scratch value is dereferenced as a kernel pointer, producing a general protection fault on a non-canonical address such as 0x1010000800004a0.
Root Cause
The root cause is the failure to clear the skb->dev field after dev_scratch consumption but before the buffer is passed to BPF verdict programs that may interpret the field as a device pointer. The union-based field reuse pattern in sk_buff is safe only while all consumers agree on the current interpretation. The sockmap verdict path violates that contract.
Attack Vector
An attacker with the ability to load BPF programs and create sockmaps (typically CAP_BPF or CAP_NET_ADMIN, or unprivileged where permitted) attaches an SK_SKB verdict program containing a socket-lookup helper invocation. The attacker then sends a UDP datagram to a socket enrolled in the sockmap. Reception in softirq triggers the verdict program, which dereferences the stale scratch value and crashes the kernel. The crash trace reported in the upstream commit places the fault in bpf_skc_lookup at net/core/filter.c:7033, called from sk_psock_verdict_recv via udp_read_skb.
The upstream fix clears skb->dev before invoking the verdict actor, so bpf_skc_lookup() falls back to sock_net(skb->sk) which was set by skb_set_owner_sk_safe() immediately prior. See the upstream patch for the corrective change.
Detection Methods for CVE-2026-53184
Indicators of Compromise
- Kernel oops messages referencing general protection fault, probably for non-canonical address with RIP pointing to bpf_skc_lookup or bpf_sk_lookup in net/core/filter.c.
- Call traces showing sk_psock_verdict_recv → udp_read_skb → sk_psock_verdict_data_ready inside <IRQ> context.
- Unexpected node crashes on systems running BPF sockmap workloads that attach SK_SKB verdict programs to UDP sockets.
Detection Strategies
- Audit loaded BPF programs of type BPF_PROG_TYPE_SK_SKB and identify those calling bpf_sk_lookup_tcp, bpf_sk_lookup_udp, or bpf_skc_lookup_tcp helpers.
- Inventory sockmap and sockhash maps containing UDP sockets via bpftool map dump and correlate with attached verdict programs.
- Monitor dmesg and journalctl -k for general protection fault traces matching the signature above.
Monitoring Recommendations
- Forward kernel crash telemetry and kdump artifacts to a centralized logging platform for signature matching on bpf_skc_lookup faults.
- Track BPF program load events (bpf() syscall with BPF_PROG_LOAD) from non-root users on production kernels.
- Alert on repeated host reboots or softirq panics on hosts running service mesh or load balancer workloads that rely on sockmap UDP redirection.
How to Mitigate CVE-2026-53184
Immediate Actions Required
- Apply the upstream stable kernel patch that clears skb->dev prior to invoking the sockmap verdict actor on the UDP receive path.
- Restrict the ability to load BPF programs to trusted administrators by disabling kernel.unprivileged_bpf_disabled=1 where it is not already enforced.
- Reboot affected nodes after patch installation so the new kernel is active in production.
Patch Information
The fix is distributed across multiple stable branches via commits 1b585673, 263779a6, 3c94f241, 6822eed6, 7d6d92d0, and 90d35188. Distribution-supplied kernels should be updated to the version that incorporates these backports.
Workarounds
- Avoid attaching SK_SKB verdict programs that invoke socket-lookup helpers to UDP sockets enrolled in sockmaps until patched kernels are deployed.
- Set sysctl -w kernel.unprivileged_bpf_disabled=1 to prevent unprivileged loading of the offending program types.
- Remove UDP sockets from sockmap/sockhash maps on unpatched hosts where verdict programs cannot be modified.
# Disable unprivileged BPF program loading until patched kernels are deployed
sysctl -w kernel.unprivileged_bpf_disabled=1
echo 'kernel.unprivileged_bpf_disabled=1' >> /etc/sysctl.d/90-bpf-hardening.conf
# Identify SK_SKB verdict programs and sockmap maps in use
bpftool prog show | grep -i sk_skb
bpftool map show | grep -iE 'sockmap|sockhash'
Disclaimer: This content was generated using AI. While we strive for accuracy, please verify critical information with official sources.

