CVE-2026-53034: Linux Kernel af_unix Sockmap Null-Pointer Dereference DoS

Technical summary

CVE-2026-53034 is a null-pointer dereference vulnerability in the Linux kernel's af_unix and BPF sockmap subsystems. The root cause is a race condition in unix_stream_connect(), which uses WRITE_ONCE() to set sk_state to TCP_ESTABLISHED before assigning the peer socket via unix_peer(sk) = newsk. This creates a time-of-check-time-of-use (TOCTOU) window where sock_map_sk_state_allowed() evaluates the socket state as established, causing unix_stream_bpf_update_proto() to proceed with peer access. Meanwhile, CPU1 executing connect() has not yet assigned the peer, resulting in a null-pointer dereference at offset 0x80 in the RIP. The fix implements a null-check within unix_stream_bpf_update_proto() to validate the peer socket before dereferencing it, avoiding the need for additional locking that would risk deadlock in softirq context BPF programs. The vulnerability affects sockmap updates initiated both via direct bpf() syscalls (BPF_MAP_UPDATE_ELEM) and from within allowed BPF program types (SCHED_CLS, SCHED_ACT, and others).

Business impact

This vulnerability enables local denial-of-service attacks against systems running vulnerable Linux kernels, particularly those that permit unprivileged BPF program loading or use container orchestration with BPF-based network policies. The crash impacts system availability, potentially disrupting services that depend on kernel stability. For organizations using eBPF for observability, load-balancing, or security enforcement, this bug creates operational risk. The attack requires local access and BPF loading privileges, limiting exposure in heavily restricted environments but posing concern for multi-tenant systems, Kubernetes clusters, and development environments where BPF programs are dynamically loaded. Rapid patching is advisable to prevent triggering the crash through malformed workload deployment.

Affected systems

The Linux kernel is affected. The vulnerability requires a system configuration that permits BPF program loading (specifically programs of type BPF_PROG_TYPE_SCHED_CLS, BPF_PROG_TYPE_SCHED_ACT, or the other specified types that can invoke sockmap updates), combined with the ability to establish Unix domain stream socket connections. Systems with BPF LSM enabled, containerized workloads using BPF-based CNI plugins, or development systems with BPF tooling are most at risk. To confirm if your system is vulnerable, verify the kernel version against available patches and check whether unprivileged BPF is enabled (kernel.unprivileged_bpf_disabled sysctl setting).

Exploitability

Exploitability requires local access and the CAP_BPF and CAP_PERFMON capabilities (or equivalent privileges to load BPF programs). The attack is straightforward: load a BPF program of an allowed type that calls bpf_sock_map_update() or similar sockmap functions, then trigger Unix domain stream socket connections concurrently. The narrow race window is not difficult to hit under normal workload conditions. No user interaction is required. The CVSS score of 5.5 (MEDIUM) reflects the local requirement and privilege constraint, though operational impact is high due to kernel panic. Systems permitting unprivileged BPF loading are at significantly higher risk.

Remediation

Apply a kernel patch that includes the null-check for peer sockets in unix_stream_bpf_update_proto(). This fix validates that unix_peer(sk) is not NULL before attempting to access its fields, preventing the dereference. The patch does not introduce additional locking, avoiding deadlock risks with softirq-context BPF programs. Verify that the patch is included in your kernel source tree and rebuild or obtain a kernel image from your vendor.

Patch guidance

Consult your Linux distribution's advisory or the upstream Linux kernel repositories for patch availability. The fix was merged into the mainline kernel to address this issue. Verify the specific kernel version number against vendor advisories (e.g., Red Hat, Ubuntu, Debian, SUSE) for the corresponding patched release. Test patches in a non-production environment before deployment. For systems unable to update immediately, consider restricting BPF program loading via sysctl (kernel.unprivileged_bpf_disabled = 2) or AppArmor/SELinux policies to reduce attack surface.

Detection guidance

Monitor kernel logs for NULL pointer dereference panic messages originating from unix_stream_bpf_update_proto() or the BPF sockmap path. A crash will appear as a hard kernel fault with a register dump pointing to address 0x0 or the null-dereference offset. Alerting on unexpected kernel panics related to BPF operations can surface exploitation attempts. Additionally, log all BPF program loading attempts (audit: -a always,exit -F arch=x86_64 -S bpf, etc.) to correlate suspicious program loads with subsequent crashes.

Why prioritize this

Although CVSS is MEDIUM (5.5), the practical impact is denial of service to the entire system via kernel panic. For production systems, especially those hosting multi-tenant workloads or relying on BPF for networking or security policy, rapid patching is warranted. The narrow race window means crashes may occur sporadically, making the vulnerability difficult to diagnose without kernel symbols. Systems with high availability requirements should prioritize this patch. Conversely, systems with strict BPF loading restrictions and no dynamic eBPF workloads may defer patching if they can tolerate the residual risk.

Risk score, explained

The CVSS 3.1 score of 5.5 is driven by: (1) Attack Vector = Local (reduces severity), (2) Privileges Required = Low (BPF capabilities are required, not full root), (3) Confidentiality = None (no data disclosure), (4) Integrity = None (no data corruption), (5) Availability = High (kernel panic is a complete availability loss). The score appropriately reflects the local boundary and privilege requirements while acknowledging the severe availability impact. Real-world risk may be higher for systems permitting unprivileged BPF or lower for air-gapped systems with strict BPF controls.

Frequently asked questions