CVE-2026-53005

What it actually does

This is a Linux kernel memory-safety flaw in the interaction between AF_UNIX socket file-descriptor passing, SCM ancillary data, and BPF SOCKMAP redirection. When an AF_UNIX socket message containing an inflight file descriptor is redirected through SOCKMAP, the socket buffer can be moved into a psock ingress queue that the AF_UNIX garbage collector cannot inspect. This can hide referenced sockets from garbage collection, leak inflight socket references, corrupt AF_UNIX garbage-collector accounting, and break assumptions in the Tarjan-based AF_UNIX GC that referenced successor sockets are still alive. Under the right timing, this can produce a kernel use-after-free in AF_UNIX garbage-collection paths such as unix_del_edges(), potentially causing kernel memory corruption, denial of service, or, if weaponized, local privilege escalation. The upstream fix drops SCM attributes before passing socket buffers to the SOCKMAP layer because sk_msg_recvmsg() does not support SCM attributes.

Why it matters to the business

Successful exploitation can destabilize Linux systems by triggering kernel crashes or hangs and may create a path to local privilege escalation if an attacker can reliably turn the use-after-free into code execution. The most exposed systems are multi-user Linux hosts, container platforms, CI runners, shared development systems, and workloads that allow untrusted users or containers to exercise AF_UNIX sockets and BPF/SOCKMAP functionality. Exploitation maturity is currently reported as none, EPSS is low, and the issue is not in the CISA Known Exploited Vulnerabilities catalog, but kernel memory-corruption bugs should still be prioritized because public proof-of-concept research can quickly change exploitability.

How an attack unfolds

An attacker first needs local code execution or a local workload context on a vulnerable Linux system. They create AF_UNIX socket pairs and pass file descriptors using SCM_RIGHTS so that sockets become inflight references tracked by AF_UNIX garbage collection. They then use BPF SOCKMAP or related psock redirection so that a socket buffer carrying SCM metadata is redirected into a psock ingress queue. Because the AF_UNIX garbage collector cannot inspect that queue, the inflight descriptor relationship can be hidden from GC. During cleanup, destruction, or garbage-collection activity, the kernel may process stale AF_UNIX graph edges and dereference a socket object that has already been freed, producing a use-after-free in the AF_UNIX GC path. A basic exploit would aim to crash the kernel for denial of service; a more advanced exploit would attempt heap shaping and object reuse to convert the dangling pointer access into controlled kernel memory corruption and possible privilege escalation.

How to fix it

Apply the vendor-supplied Linux kernel update that contains the AF_UNIX/SOCKMAP fix which drops SCM attributes before passing socket buffers into the SOCKMAP layer. Because no product-specific fixed versions were provided, use your distribution or appliance vendor advisory to identify the first fixed kernel for each affected release stream. Reboot into the patched kernel after installation; simply installing kernel packages is not sufficient if the system continues running the vulnerable kernel. Where immediate patching is not possible, reduce exposure by disabling unprivileged BPF where operationally feasible, restricting CAP_BPF and CAP_NET_ADMIN to trusted workloads only, limiting untrusted container privileges, avoiding privileged containers, and enforcing seccomp/AppArmor/SELinux policies that reduce access to BPF and high-risk socket operations. Treat mitigations as risk reduction only; the durable fix is a patched kernel.

How to confirm the fix worked

Confirm the running kernel, not just the installed package, is updated to a vendor kernel containing the fix. On Linux systems, compare `uname -a` and package-manager output against the distribution advisory for this vulnerability. Validate that systems have been rebooted after kernel updates. Where available, check vendor changelogs or source packages for the AF_UNIX/SOCKMAP change described as dropping SCM attributes for SOCKMAP or related changes in `net/unix/af_unix.c`, `net/unix/garbage.c`, or psock/SOCKMAP paths. Confirm risk-reduction controls by checking whether unprivileged BPF is disabled, whether only trusted services hold CAP_BPF or CAP_NET_ADMIN, and whether container profiles prevent untrusted workloads from using BPF/SOCKMAP primitives. For exposure assessment, inventory Linux kernels across servers, container hosts, appliances, and embedded systems rather than relying only on application dependency scans.

Typical attack path

1. Obtain local execution on a Linux host, container, or shared workload where AF_UNIX sockets are available.
2. Determine whether BPF SOCKMAP functionality can be used from that context, typically depending on kernel configuration, capabilities, namespace policy, and unprivileged BPF restrictions.
3. Create AF_UNIX socket pairs and send file descriptors through them using SCM_RIGHTS ancillary data.
4. Attach or use SOCKMAP/psock redirection so socket buffers carrying SCM attributes are redirected into a queue not visible to AF_UNIX garbage collection.
5. Trigger socket teardown, garbage collection, or psock backlog processing to create inconsistent AF_UNIX GC state.
6. Cause the kernel to dereference freed AF_UNIX socket state, resulting in a crash or potentially exploitable kernel memory corruption.
7. Optionally attempt heap grooming and repeated triggering to convert the use-after-free into local privilege escalation.

How to detect it

Look for evidence in kernel logs, system journals, crash dumps, and endpoint telemetry showing AF_UNIX garbage-collection failures or psock/SOCKMAP backlog crashes. Primary log sources include `dmesg`, `journalctl -k`, `/var/log/kern.log`, `/var/log/messages`, `/var/log/syslog`, kernel crash dump facilities such as kdump/vmcore, and EDR telemetry that captures kernel oops or panic events. Search for KASAN reports or kernel oops traces containing `slab-use-after-free`, `unix_del_edges`, `unix_destroy_fpl`, `unix_destruct_scm`, `sk_psock_backlog`, `sk_psock_destroy`, or references to AF_UNIX garbage collection. Also review audit logs for suspicious local use of BPF-related syscalls, repeated creation of AF_UNIX socket pairs, and processes acquiring CAP_BPF or CAP_NET_ADMIN immediately before a crash, though these events are behavioral and not unique to this vulnerability. If crash dumps are available, examine stack traces for AF_UNIX GC and psock functions and correlate the time of the crash with local user sessions, container starts, BPF program loads, or unusual high-rate socket activity.

• BUG: KASAN: slab-use-after-free in unix_del_edges
• slab-use-after-free in unix_del_edges
• unix_del_edges
• unix_destroy_fpl
• unix_destruct_scm
• sk_psock_backlog
• sk_psock_destroy
• Workqueue: events sk_psock_backlog
• af_unix
• SOCKMAP
• psock->ingress_skb
• SCM_RIGHTS
• __sys_socketpair
• __x64_sys_socketpair
• kernel.unprivileged_bpf_disabled
• CAP_BPF
• CAP_NET_ADMIN

What your security team should do

• Prioritize patching shared Linux hosts, container nodes, CI runners, bastion systems, and any environment where untrusted users or workloads can run local code.
• Reboot systems after kernel updates and verify the running kernel version is the fixed version from the vendor advisory.
• Disable unprivileged BPF where feasible, commonly via the distribution-supported control for `kernel.unprivileged_bpf_disabled`, and monitor for drift.
• Restrict CAP_BPF, CAP_NET_ADMIN, and privileged container usage to explicitly trusted workloads.
• Review container runtime, Kubernetes, and workload security policies to prevent untrusted workloads from loading BPF programs or using elevated networking capabilities.
• Add detection for kernel warnings, KASAN splats, AF_UNIX garbage-collection crashes, and psock/SOCKMAP-related kernel oops messages.
• Investigate unexplained kernel panics involving `unix_del_edges`, `unix_destroy_fpl`, `unix_destruct_scm`, `sk_psock_backlog`, or `sk_psock_destroy` as potentially related activity.
• Track EPSS, exploit publication, and distribution advisories because current low exploitation maturity can change quickly for kernel memory-corruption vulnerabilities.