CVE-2026-53033

What it actually does

This is a Linux kernel use-after-free race in the AF_UNIX socket and BPF sockmap/iterator interaction. A BPF iterator program that updates a sockmap can observe a peer UNIX stream socket while another thread is closing the same socket; without holding the appropriate socket state lock, the peer pointer can be cleared and freed before unix_stream_bpf_update_proto() takes a reference to it. The result is a stale kernel pointer dereference/write in kernel context, which can cause kernel memory corruption, kernel crash, and, depending on allocator state and exploitability, potential local privilege escalation. Practical exploitation generally requires local code execution plus the ability to load/run BPF programs or otherwise access privileged BPF functionality.

Why it matters to the business

Affected Linux systems may be exposed to local denial-of-service and possible privilege escalation from a user, workload, container, or compromised process that can use BPF features. The current public exploitation signal is low: EPSS is 0.00135, it is not listed in CISA KEV, no ransomware association is reported, and exploit maturity is listed as none. However, because this flaw is in the kernel, successful exploitation can undermine host isolation and availability, especially on multi-user systems, container platforms, build hosts, and environments where BPF access is permitted.

How an attack unfolds

An attacker first obtains the ability to execute code on a Linux host and confirms that BPF program loading or BPF iterator functionality is available to their security context. They create AF_UNIX stream sockets and a sockmap, then load or trigger a BPF iterator program that updates the sockmap while a concurrent thread closes the related UNIX socket. By repeatedly racing the BPF sockmap update path against the socket close path, the attacker attempts to make unix_stream_bpf_update_proto() use a peer socket pointer after it has been detached and freed by unix_release_sock(). In the simplest outcome, the host logs a kernel use-after-free warning, oops, or panic. A more advanced attacker would try to shape kernel heap reuse around the freed socket object to turn the memory corruption into controlled kernel execution or privilege escalation. No public weaponized exploit or known in-the-wild campaign is indicated by the provided data.

How to fix it

Apply the Linux kernel update from the relevant distribution or kernel vendor that includes the fix for the AF_UNIX BPF sockmap iterator locking issue, then reboot into the fixed kernel. If exact fixed package versions are not available from the vulnerability metadata, use the vendor advisory for the deployed distribution and confirm the running kernel build contains the upstream fix described as taking the state lock for AF_UNIX iterator sockmap updates. As interim risk reduction, disable unprivileged BPF where supported, restrict CAP_BPF, CAP_SYS_ADMIN, and CAP_NET_ADMIN to trusted users and workloads only, prevent untrusted containers from loading BPF programs, apply seccomp/AppArmor/SELinux profiles that block unnecessary bpf() syscall use, and reduce local shell access on shared hosts. Mitigations should not be treated as complete substitutes for a kernel update because privileged or partially privileged workloads may still reach BPF functionality.

How to confirm the fix worked

Confirm the system is booted into a kernel version that includes the vendor fix, not merely that the package is installed. Validate with uname -a, distribution package metadata, and the vendor security advisory or changelog for the fixed kernel. Check whether unprivileged BPF is disabled using /proc/sys/kernel/unprivileged_bpf_disabled where available, and review which users, services, and containers retain BPF-related capabilities. On test systems only, kernel selftests or vendor regression tests for BPF sockmap/AF_UNIX behavior can be used to confirm the race no longer triggers KASAN or kernel warnings. In production, absence of crashes is not proof of remediation; rely on running-kernel version verification and configuration review.

Typical attack path

1. Gain local code execution on a Linux system, such as through a shell, compromised workload, or malicious local user account.
2. Determine whether BPF program loading, BPF iterators, and sockmap functionality are available under the current privileges or namespace/container configuration.
3. Create AF_UNIX stream sockets and a BPF sockmap suitable for exercising the vulnerable kernel path.
4. Run a BPF iterator program that updates the sockmap while another execution thread repeatedly closes or transitions the peer UNIX socket state.
5. Trigger the race where unix_peer(sk) becomes stale between lookup and sock_hold(sk_pair).
6. Cause kernel memory corruption, typically observed as a KASAN report, oops, panic, or service disruption; with additional exploitation work, attempt privilege escalation.

How to detect it

Retrospective exploitation detection is difficult because a failed or successful kernel memory corruption attempt may leave little durable evidence beyond kernel logs and process/audit telemetry. Review journald, dmesg, syslog, kern.log, crash dumps, kdump/vmcore records, and EDR telemetry for kernel warnings or crashes involving BPF sockmaps, AF_UNIX sockets, and the listed kernel functions. If Linux auditd is enabled, review bpf() syscall events, BPF_PROG_LOAD operations, and privilege/capability use around the time of crashes or anomalous host behavior. Inspect process execution logs for bpftool, custom BPF loaders, unusual test binaries, or short-lived processes that create BPF maps/programs. On container hosts, correlate kernel oops/panic timestamps with workload starts, privileged container launches, capability changes, and pods/containers granted BPF-related access. Because the provided intelligence does not identify active threat actors or public exploit tooling, detections should focus on behavioral evidence: unexpected BPF program loading by untrusted principals, repeated AF_UNIX socket churn paired with BPF activity, and kernel crash signatures matching the vulnerable call path.

• BUG: KASAN: slab-use-after-free in unix_stream_bpf_update_proto
• slab-use-after-free in unix_stream_bpf_update_proto
• unix_stream_bpf_update_proto
• sock_map_link
• sock_map_update_common
• sock_map_update_elem
• bpf_iter_run_prog
• bpf_iter_unix_seq_show
• bpf_seq_read
• unix_release_sock
• unix_peer(sk) = NULL
• BPF_PROG_LOAD
• __x64_sys_bpf
• bpftool prog load
• bpftool map create
• /proc/sys/kernel/unprivileged_bpf_disabled
• kernel: BUG: KASAN
• kernel: Oops
• kernel panic
• general protection fault

What your security team should do

• Prioritize patching shared Linux hosts, container nodes, CI/build systems, bastion hosts, and systems where untrusted users or workloads may execute code.
• Reboot after kernel update and verify the active running kernel contains the fix.
• Disable unprivileged BPF where operationally feasible and tightly control CAP_BPF, CAP_SYS_ADMIN, and CAP_NET_ADMIN assignments.
• Audit container runtime and orchestration policies to ensure untrusted workloads cannot load arbitrary BPF programs or run with excessive Linux capabilities.
• Hunt recent kernel logs for KASAN, use-after-free, oops, panic, and call traces involving unix_stream_bpf_update_proto, sock_map_update_elem, bpf_iter_run_prog, or unix_release_sock.
• Monitor audit/eBPF telemetry for unexpected bpf() syscall usage, BPF_PROG_LOAD activity, sockmap creation, or bpftool execution by non-administrative users.
• Treat unexpected kernel crashes involving BPF and AF_UNIX sockets as potentially suspicious, even though no public exploitation is currently indicated.
• Track distribution advisories because fixed package names and versions vary by kernel branch and vendor backport policy.