CVE-2026-53184

What it actually does

This is a Linux kernel denial-of-service flaw in the UDP receive path when UDP sockets are used with sockmap/sockhash and an attached SK_SKB eBPF verdict program. The kernel reuses the sk_buff `skb->dev` field as UDP scratch storage, but before running the sockmap verdict program it failed to clear that field. If the verdict program invokes socket lookup helpers such as `bpf_sk_lookup_tcp`, `bpf_sk_lookup_udp`, or `bpf_skc_lookup_tcp`, the helper may treat the stale scratch value as a `struct net_device *` and dereference an invalid, non-canonical address. This can trigger a general protection fault in softirq context, potentially causing a kernel oops, service disruption, or system crash depending on kernel configuration.

Why it matters to the business

Successful exploitation can disrupt Linux hosts by crashing or destabilizing the kernel networking path, affecting applications, containers, or services that depend on the impacted system. The practical risk is lower than many remotely exploitable kernel bugs because exploitation generally requires the ability to load and attach eBPF sockmap programs or otherwise control privileged networking/BPF behavior. The vulnerability is not currently listed in CISA KEV, is not known to be used in ransomware campaigns, has low EPSS, and has no public exploit maturity reported, but kernel denial-of-service issues should still be prioritized on multi-tenant, container, edge, and high-availability systems where a local crash can cause broad operational impact.

How an attack unfolds

An attacker first obtains local code execution with sufficient privileges to use eBPF and sockmap functionality, typically requiring capabilities such as CAP_BPF, CAP_NET_ADMIN, CAP_SYS_ADMIN, or permissive unprivileged BPF settings. The attacker creates or uses a UDP socket that is placed into a sockmap or sockhash, then attaches an SK_SKB verdict program that calls one of the BPF socket lookup helpers. The attacker then sends or causes delivery of a UDP packet to that socket, commonly over IPv6 based on the reported crash path. During UDP receive processing, the kernel runs the sockmap verdict in softirq context while `skb->dev` still contains stale UDP scratch data. The BPF helper interprets that stale value as a network device pointer and dereferences it, causing a general protection fault. Depending on kernel panic/oops behavior and workload, this may terminate kernel processing, crash the host, or cause significant service instability.

How to fix it

Apply the Linux kernel update from the relevant distribution or kernel vendor that includes the fix for clearing `skb->dev` before running a sockmap verdict on the UDP receive path. Because no exact product or package fixed versions were provided, use vendor advisories and package changelogs to identify kernels containing the upstream fix titled `udp: clear skb->dev before running a sockmap verdict`. Prioritize upgrades on systems that allow eBPF program loading, run privileged containers, expose BPF to workloads, use Cilium/other eBPF-heavy networking components, or host untrusted users. As interim mitigations, disable unprivileged BPF where possible with `kernel.unprivileged_bpf_disabled=1`, restrict CAP_BPF/CAP_NET_ADMIN/CAP_SYS_ADMIN, prevent privileged container use unless required, enforce seccomp/AppArmor/SELinux policies that block BPF program loading, and limit access to tooling that can create sockmaps and attach SK_SKB programs. These mitigations reduce exploitability but do not replace a kernel fix.

How to confirm the fix worked

Confirm remediation by verifying that the running kernel package is at or above the vendor-fixed version and that the applied kernel changelog contains the UDP sockmap fix for clearing `skb->dev` before verdict execution. Reboot into the updated kernel where required and verify with `uname -a` and distribution package tools such as `rpm -q kernel`, `dpkg -l 'linux-image*'`, or vendor-specific inventory tooling. Confirm exposure reduction by checking whether unprivileged BPF is disabled using `sysctl kernel.unprivileged_bpf_disabled`, and review container/runtime policy to ensure untrusted workloads do not receive CAP_BPF, CAP_NET_ADMIN, CAP_SYS_ADMIN, or privileged mode. In non-production test environments only, validation can include running a controlled BPF/sockmap regression test that exercises UDP sockmap verdict programs with socket lookup helpers and confirms no kernel oops occurs.

Typical attack path

1. Gain local execution on a vulnerable Linux system or inside a sufficiently privileged container.
2. Confirm that eBPF, sockmap/sockhash, and required BPF helpers are available and not blocked by policy.
3. Create a UDP socket and insert it into a sockmap or sockhash.
4. Attach an SK_SKB verdict eBPF program that invokes a socket lookup helper such as `bpf_sk_lookup_udp`, `bpf_sk_lookup_tcp`, or `bpf_skc_lookup_tcp`.
5. Send or trigger receipt of UDP traffic to the mapped socket.
6. Cause the kernel UDP receive path to run the verdict program while `skb->dev` contains stale scratch data.
7. Trigger a kernel general protection fault in `bpf_skc_lookup`/`bpf_sk_lookup`, resulting in denial of service.

How to detect it

Look for evidence of kernel crashes or oopses in kernel log sources such as `dmesg`, `journalctl -k`, `/var/log/kern.log`, `/var/log/messages`, `/var/log/syslog`, crash dump directories, and centralized EDR/SIEM telemetry. The most relevant artifacts are general protection faults or oops traces containing BPF socket lookup and sockmap verdict functions, especially `bpf_skc_lookup`, `bpf_sk_lookup`, `sk_psock_verdict_recv`, `udp_read_skb`, `sk_psock_verdict_data_ready`, `__udp_enqueue_schedule_skb`, `udpv6_queue_rcv_one_skb`, or `udp6_unicast_rcv_skb`. Correlate crash timing with audit logs showing BPF program load or map creation activity, privileged container launches, capability changes, execution of BPF tooling, or abnormal UDP traffic to local services. Useful audit sources include Linux auditd syscall records for `bpf`, container runtime logs, Kubernetes audit logs for privileged pods or added capabilities, EDR process telemetry, and shell history where available. Because this vulnerability produces a crash rather than a durable file artifact, detection is primarily log- and crash-trace-based; absence of these indicators does not prove non-exploitation if kernel logs rotated or the system rebooted without persistent logging.

• general protection fault, probably for non-canonical address
• Oops: general protection fault
• RIP: 0010:bpf_skc_lookup
• RIP: 0010:bpf_sk_lookup
• bpf_skc_lookup net/core/filter.c
• bpf_sk_lookup net/core/filter.c
• bpf_prog_run_pin_on_cpu
• sk_psock_verdict_recv
• udp_read_skb
• sk_psock_verdict_data_ready
• __udp_enqueue_schedule_skb
• udpv6_queue_rcv_one_skb
• udp6_unicast_rcv_skb
• ip6_protocol_deliver_rcu
• net_rx_action
• handle_softirqs
• syscall=bpf
• comm="bpftool"
• comm="tc"

What your security team should do

• Inventory Linux systems running kernels released before the vendor fix and prioritize internet-facing, multi-tenant, container-hosting, and high-availability systems.
• Patch affected kernels using distribution-supported updates and reboot into the fixed kernel as soon as operationally feasible.
• Disable unprivileged BPF and remove unnecessary CAP_BPF, CAP_NET_ADMIN, CAP_SYS_ADMIN, and privileged-container access from workloads and users.
• Review usage of eBPF networking stacks, sockmap/sockhash programs, service meshes, and container networking components to identify hosts where the vulnerable code path may be reachable.
• Monitor kernel logs for general protection faults involving BPF socket lookup helpers, UDP receive processing, or sockmap verdict functions.
• If suspicious crashes are observed, preserve kernel logs, crash dumps, BPF program inventory, container audit logs, and process execution history before rebooting or rebuilding.
• Treat repeated kernel oopses with the relevant stack trace as a potential local denial-of-service attempt, especially on shared systems or hosts running untrusted workloads.