CVE-2026-53035

What it actually does

This Linux kernel flaw is a local denial-of-service condition in the eBPF sockmap and AF_UNIX iterator path. When an eBPF iterator program walks UNIX-domain sockets and attempts to update a sockmap, the kernel can recursively acquire the same AF_UNIX socket spinlock through bpf_iter_unix_seq_show(), lock_sock_fast(), and sock_map_update_elem(). The result is a kernel deadlock or lockup condition rather than code execution or privilege escalation. Practical exploitation requires the ability to load and run relevant eBPF programs and interact with sockmaps, which is typically restricted to privileged users or systems where unprivileged eBPF is enabled.

Why it matters to the business

Successful exploitation can freeze affected kernel execution paths, degrade host responsiveness, or force a reboot, causing workload interruption and potential service downtime. The risk is highest on multi-tenant Linux hosts, container platforms, CI systems, developer machines, or performance/observability environments where users or services can load eBPF programs. This issue is not currently listed in CISA KEV, is not known to be used in ransomware campaigns, has no reported public exploit maturity, and has a very low EPSS score, so remediation should be handled through normal kernel patch management unless eBPF is broadly available to untrusted users.

How an attack unfolds

An attacker first needs local execution on an affected Linux system and sufficient permission to create or load eBPF programs that use BPF iterators and sockmaps. The attacker prepares an eBPF iterator program that enumerates AF_UNIX sockets and, during the iterator callback, performs a sockmap update against a socket already locked by the iterator path. When the program is triggered through the BPF sequence file read path, the kernel takes the fast socket-locking path, then attempts to take the same AF_UNIX socket lock again inside sock_map_update_elem(). This recursive lock acquisition can deadlock the kernel path, leading to a denial of service. Because the condition depends on eBPF capabilities and kernel locking behavior, exploitation is local and configuration-dependent.

How to fix it

Upgrade to a Linux kernel version that includes the upstream fix for the eBPF sockmap AF_UNIX iterator deadlock. If distribution-specific fixed kernel versions are not yet identified, track the relevant vendor security advisory and install the latest stable or long-term-support kernel update containing the fix. Reboot systems after applying the patched kernel so the running kernel is actually updated. As interim risk reduction, disable unprivileged eBPF where possible by setting kernel.unprivileged_bpf_disabled=1, restrict CAP_BPF, CAP_SYS_ADMIN, and CAP_NET_ADMIN to trusted workloads only, prevent untrusted containers from using privileged mode or BPF-related capabilities, and limit access to BPF filesystem and tracing interfaces. These mitigations reduce exploitability but do not replace applying the fixed kernel.

How to confirm the fix worked

Confirm the running kernel has been updated, not just that a package is installed. Check the active kernel with uname -a or equivalent fleet inventory and compare it against the distribution advisory that contains the fix. Verify unprivileged BPF is disabled where required by checking /proc/sys/kernel/unprivileged_bpf_disabled or sysctl kernel.unprivileged_bpf_disabled. Review container and service profiles to ensure untrusted workloads do not have CAP_BPF, CAP_SYS_ADMIN, CAP_NET_ADMIN, privileged container mode, or broad access to /sys/fs/bpf. After patching and rebooting, monitor kernel logs for absence of recursive-locking warnings involving AF_UNIX, sock_map_update_elem(), bpf_iter_unix_seq_show(), and bpf_seq_read.

Typical attack path

1. Gain local code execution on an affected Linux host, container host, or developer/CI system.
2. Confirm that eBPF program loading is permitted, either through elevated privileges such as CAP_BPF/CAP_SYS_ADMIN or through permissive unprivileged BPF settings.
3. Create AF_UNIX sockets and a sockmap suitable for triggering the vulnerable path.
4. Load an eBPF iterator program that enumerates UNIX-domain sockets and attempts to update the sockmap during iteration.
5. Trigger the iterator read path so bpf_iter_unix_seq_show() runs the program while the socket lock is already held.
6. Cause recursive acquisition of the AF_UNIX socket lock in sock_map_update_elem(), producing a deadlock or kernel lockup.
7. Repeat or sustain the trigger to cause host-level service degradation or denial of service.

How to detect it

Look for evidence of kernel deadlock warnings and suspicious eBPF activity before or during service degradation. Primary log sources include dmesg, journald, /var/log/kern.log, /var/log/messages, /var/log/syslog, auditd, endpoint telemetry, and container runtime logs. Search for kernel warnings containing "possible recursive locking detected", "DEADLOCK", "slock-AF_UNIX", "sock_map_update_elem", "bpf_iter_unix_seq_show", or "bpf_seq_read". Correlate timestamps with process execution, container starts, CI jobs, bpftool activity, BPF program loads, changes under /sys/fs/bpf, and grants of CAP_BPF, CAP_SYS_ADMIN, or CAP_NET_ADMIN. In audit logs, review bpf-related syscalls and processes opening or pinning BPF objects. Affected exploitation is unlikely to leave network IOCs; host telemetry and kernel logs are the most useful evidence sources.

• WARNING: possible recursive locking detected
• *** DEADLOCK ***
• slock-AF_UNIX
• sk_lock-AF_UNIX
• sock_map_update_elem
• bpf_iter_unix_seq_show
• bpf_iter_run_prog
• bpf_seq_read
• __lock_sock_fast
• lock_sock_fast
• bpf_prog_2d0075e5d9b721cd_dump_unix
• /sys/fs/bpf
• kernel.unprivileged_bpf_disabled
• CAP_BPF
• CAP_SYS_ADMIN
• CAP_NET_ADMIN

What your security team should do

• Prioritize patching Linux systems that allow local users, CI jobs, containers, observability agents, or developer workloads to load eBPF programs.
• Apply vendor-provided fixed kernel updates and reboot affected hosts to ensure the patched kernel is running.
• Disable unprivileged eBPF unless there is a documented business requirement for it.
• Audit and minimize assignment of CAP_BPF, CAP_SYS_ADMIN, CAP_NET_ADMIN, privileged container mode, and access to /sys/fs/bpf.
• Review endpoint, audit, and container telemetry for unexpected BPF program loading or sockmap activity by non-platform processes.
• Add kernel-log detections for recursive locking or deadlock warnings involving AF_UNIX socket locks and BPF sockmap functions.
• Treat exploitation as a local denial-of-service scenario; focus response on identifying the initiating local process, container, job, or user rather than remote network indicators.
• Because this is not KEV-listed, not known ransomware-used, and has low EPSS, handle through normal but timely kernel maintenance unless the environment exposes eBPF to untrusted users.