CVE-2026-64109

What it actually does

This is a Linux kernel use-after-free condition in the AF_UNIX stream socket implementation. The vulnerable code path in unix_stream_data_wait() can read fields from a socket buffer (SKB) after that SKB has been dequeued and freed during a race between a peeking receive operation and a normal receive operation on the same UNIX domain stream socket. Because the bug is in kernel memory handling, a local authenticated user or process that can create and operate AF_UNIX stream sockets may be able to trigger kernel memory corruption behavior, potentially leading to kernel crash, information disclosure, or privilege escalation depending on kernel configuration, allocator behavior, hardening features, and exploit reliability.

Why it matters to the business

Successful exploitation could allow a local user, compromised application, container workload, or sandboxed process to destabilize the host or potentially gain elevated privileges on affected Linux systems. The operational risk is highest on multi-user servers, shared compute platforms, container hosts, CI/CD runners, developer workstations, and systems running untrusted or semi-trusted local code. This issue is not listed in CISA KEV, is not reported as used in ransomware campaigns, and currently has very low EPSS probability, so broad internet-driven exploitation is not indicated; however, local kernel privilege-escalation bugs are often valuable after initial compromise and should be patched through normal high-priority kernel maintenance.

How an attack unfolds

An attacker must first obtain the ability to run code locally on an affected Linux system. They then exercise AF_UNIX stream socket behavior by creating a UNIX domain socket pair and causing two operations to race on the receiving socket: one path performs a peeking receive with an offset, while another concurrently consumes data and shuts down or changes socket state. In the vulnerable kernel, unix_stream_data_wait() can retain a reference-like comparison to the tail SKB without holding the lock needed to prevent that SKB from being removed and freed. If timing is won, the function may dereference the stale SKB pointer and read tail->len after the memory has been freed. In the simplest case this can crash the kernel; in a more advanced exploit, an attacker may attempt heap grooming and object reuse to turn the race into a controlled kernel memory primitive for privilege escalation or information disclosure. No public exploit maturity is indicated in the provided data.

How to fix it

Apply a Linux kernel update that includes the upstream fix for the AF_UNIX unix_stream_data_wait() use-after-free. Because no specific affected product list or fixed package versions were provided, use the fixed kernel packages from the relevant Linux distribution or appliance vendor rather than attempting to backport manually. Prioritize kernels based on Linux 6.5 and later lineage where the described fix is applicable, and verify vendor advisories for exact exposure and package names. Reboot into the patched kernel after installation; merely installing kernel packages is insufficient if the host continues running the old kernel. Where immediate patching is not possible, reduce exposure by limiting local shell access, restricting execution of untrusted workloads, strengthening container isolation, disabling unnecessary multi-tenant access, and monitoring for kernel crashes or suspicious local exploit activity. There is no practical configuration-only mitigation that reliably removes AF_UNIX socket functionality from a general-purpose Linux system without significant application impact.

How to confirm the fix worked

Confirm the running kernel, not just the installed kernel package, is fixed. Check the active kernel with uname -a or equivalent fleet inventory and compare it to the distribution vendor advisory for this issue. Validate that systems have rebooted into the patched kernel after update. For source-based or custom kernels, confirm that the AF_UNIX change removing the unsafe tail->len read from unix_stream_data_wait() is present in the running build. Review kernel package changelogs for references to AF_UNIX, unix_stream_data_wait(), skb_peek_tail(), or this vulnerability. If using vulnerability scanning, ensure scanners evaluate the running kernel version and distribution backport status, because vendor kernels may include the fix without changing to an upstream mainline version number.

Typical attack path

1. Gain local code execution on an affected Linux host through an account, compromised service, container workload, or other foothold.
2. Create AF_UNIX SOCK_STREAM sockets and configure receive behavior involving peeking semantics such as SO_PEEK_OFF and MSG_PEEK.
3. Run concurrent socket receive operations that race a peeking read against a normal read and socket state changes.
4. Trigger the vulnerable unix_stream_data_wait() path so it reads an SKB field after that SKB has been freed.
5. Use the resulting kernel fault to cause denial of service, or attempt heap manipulation to convert the use-after-free into privilege escalation or information disclosure.

How to detect it

Look for evidence of attempted local kernel exploitation or resulting instability rather than remote network indicators. Useful sources include kernel logs from dmesg, journald, syslog, crash dump infrastructure, EDR process telemetry, auditd exec records, and container runtime logs. Search for kernel oops, panic, KASAN, KFENCE, or general protection fault entries referencing AF_UNIX socket handling, unix_stream_data_wait(), skb_peek_tail(), consume_skb(), or net/unix/af_unix.c. Also review recent local process execution around crash times for unusual proof-of-concept style binaries, stress loops, unexpected compiler usage, or processes repeatedly creating UNIX domain socket pairs and using peeking receive behavior. On container hosts, correlate host kernel faults with container start times, short-lived processes, and workloads that generated abnormal local socket activity. Absence of these artifacts does not prove non-exploitation, because a reliable privilege-escalation attempt may leave limited logs unless it crashes or triggers kernel diagnostics.

• BUG: KASAN: use-after-free
• KASAN: use-after-free in unix_stream_data_wait
• KFENCE: use-after-free
• general protection fault
• kernel panic
• Oops:
• unix_stream_data_wait
• net/unix/af_unix.c
• skb_peek_tail
• consume_skb
• af_unix
• SO_PEEK_OFF
• MSG_PEEK

What your security team should do

• Inventory Linux systems where local users, containers, build jobs, plugins, or application workloads can execute code, and prioritize those for patch validation.
• Apply vendor kernel updates and schedule reboots to ensure the fixed kernel is active.
• Give higher priority to shared infrastructure, container hosts, CI/CD runners, bastion hosts, academic/research clusters, VDI hosts, and developer systems where untrusted local code is more likely.
• Monitor for kernel oops, panic, KASAN, or general protection fault messages involving AF_UNIX, unix_stream_data_wait(), SKB handling, or net/unix/af_unix.c.
• Treat unexplained crashes on affected kernels as potentially security-relevant and preserve kernel logs, crash dumps, audit logs, and recent process execution telemetry.
• Do not rely on EPSS or non-KEV status as a reason to defer indefinitely; local kernel bugs are commonly chained after initial access.
• For containerized environments, verify host kernel patch status because containers share the host kernel even when container images are updated.