CVE-2026-53034

What it actually does

This is a Linux kernel race condition in the AF_UNIX stream socket and BPF sockmap interaction. During unix_stream_connect(), the socket state can briefly be marked established before its peer pointer is assigned. If a concurrent BPF sockmap update processes that socket during this window, the kernel may dereference a NULL unix_peer pointer in unix_stream_bpf_update_proto(), causing a kernel NULL pointer dereference and system crash. The practical impact is denial of service through kernel oops/panic, not known remote code execution or privilege escalation based on the provided details.

Why it matters to the business

A successful exploit can crash affected Linux systems, interrupting applications, containers, network services, and workloads running on the host. Because this requires a narrow timing race and BPF/sockmap capabilities, exploitation is more likely from local users, containers, or workloads with sufficient BPF/network privileges than from the public internet. EPSS is low and the issue is not listed in CISA KEV, but kernel denial-of-service flaws can still be operationally significant on shared compute, container platforms, CI runners, and multi-tenant Linux hosts.

How an attack unfolds

An attacker first needs local code execution on an affected Linux host and the ability to exercise BPF sockmap updates, either through the bpf() syscall or through a BPF program type permitted to update sockmaps. The attacker creates AF_UNIX stream sockets and repeatedly races connect() operations against sockmap updates. In the vulnerable window, connect() has set sk_state to TCP_ESTABLISHED, causing sockmap validation to treat the socket as usable, but unix_peer(sk) is still NULL. The sockmap update path then reaches unix_stream_bpf_update_proto(), attempts to take a reference on the missing peer, and dereferences a NULL pointer. If the race is won, the kernel logs an oops similar to a NULL pointer dereference in unix_stream_bpf_update_proto and may panic or otherwise destabilize the system, producing a denial of service.

How to fix it

Apply the vendor-provided Linux kernel update that includes the fix for the AF_UNIX sockmap NULL peer check/race. Because no specific affected product list or fixed package versions were provided, use the fixed kernel packages from the relevant Linux distribution, appliance vendor, cloud image provider, or kernel branch maintainer. Reboot into the patched kernel after installation; installing the package alone is not sufficient if the host continues running the vulnerable kernel. As interim mitigations, restrict local access to trusted users, disable unprivileged BPF where operationally feasible, limit CAP_BPF/CAP_NET_ADMIN/CAP_SYS_ADMIN exposure in containers and services, apply seccomp/AppArmor/SELinux policies that block unnecessary bpf() syscall use, and avoid granting privileged containers broad kernel interaction permissions.

How to confirm the fix worked

Confirm the running kernel, not only the installed kernel package, is patched by checking uname -a and comparing it with the distribution advisory or fixed kernel build. Verify that systems have been rebooted into the updated kernel. Review kernel package changelogs or vendor advisories for references to the AF_UNIX sockmap, unix_stream_bpf_update_proto, sock_map_update_elem, or BPF sockmap NULL pointer fix. Where mitigation is used, confirm unprivileged BPF is disabled if applicable, for example by checking kernel.unprivileged_bpf_disabled, and audit containers/services for unnecessary CAP_BPF, CAP_NET_ADMIN, CAP_SYS_ADMIN, privileged mode, and broad seccomp exceptions. Exposure is greatest where untrusted local users or containers can invoke BPF sockmap update paths.

Typical attack path

1. Obtain local execution on an affected Linux system, container host, or workload environment.
2. Confirm BPF/sockmap functionality is reachable, such as access to the bpf() syscall and required capabilities or permissive unprivileged BPF settings.
3. Create AF_UNIX stream sockets and BPF sockmaps suitable for sock_map_update_elem or equivalent BPF-driven updates.
4. Repeatedly race unix stream connect() against sockmap update operations.
5. Trigger the timing window where the socket state is established but the AF_UNIX peer pointer has not yet been assigned.
6. Cause a NULL pointer dereference in unix_stream_bpf_update_proto, resulting in kernel oops, panic, or host instability.

How to detect it

Look for evidence of prior exploitation in kernel logs, persistent journal entries, crash dumps, and host monitoring records. Relevant sources include dmesg, journalctl -k, /var/log/kern.log, /var/log/messages, /var/log/syslog, kdump/vmcore records, kernel oops reports, crash monitoring, and EDR telemetry for bpf() syscall activity. Indicators include NULL pointer dereferences with RIP or call traces involving unix_stream_bpf_update_proto, sock_map_link, sock_map_update_common, sock_map_update_elem_sys, __sys_bpf, or __x64_sys_bpf. Correlate crashes with local processes making heavy bpf() syscall usage, creating AF_UNIX sockets, or running privileged/containerized workloads with BPF or network administration capabilities. Absence of these logs does not prove absence of exploitation, because a hard panic or reboot may truncate logs unless persistent journaling or crash dump collection is enabled.

• BUG: kernel NULL pointer dereference, address: 0000000000000080
• RIP: 0010:unix_stream_bpf_update_proto
• unix_stream_bpf_update_proto+0xa0/0x1b0
• Call Trace:
• sock_map_link+0x564/0x8b0
• sock_map_update_common+0x6e/0x340
• sock_map_update_elem_sys+0x17d/0x240
• __sys_bpf+0x26db/0x3250
• __x64_sys_bpf+0x21/0x30
• do_syscall_64+0x6b/0x3a0
• entry_SYSCALL_64_after_hwframe
• kernel NULL pointer dereference
• unix_stream_bpf_update_proto
• sock_map_update_elem_sys
• sock_map_update_common
• sock_map_link
• __sys_bpf
• __x64_sys_bpf

What your security team should do

• Prioritize patching shared Linux hosts, container platforms, Kubernetes nodes, CI/build runners, developer workstations with untrusted code execution, and multi-user systems.
• Reboot systems after kernel updates and verify the active kernel version is the fixed version from the vendor advisory.
• Temporarily disable unprivileged BPF where feasible and monitor for any systems where it remains enabled.
• Reduce container and service privileges by removing CAP_BPF, CAP_NET_ADMIN, CAP_SYS_ADMIN, privileged mode, and unnecessary bpf() syscall access unless explicitly required.
• Add monitoring for kernel oops/panic messages referencing unix_stream_bpf_update_proto, sock_map_update_elem, sock_map_update_common, sock_map_link, or __sys_bpf.
• Investigate unexplained host crashes or kernel panics occurring after local BPF activity, especially on systems running untrusted workloads.
• Track distribution advisories because fixed versions vary by kernel branch and downstream vendor backporting policy.