CVE-2026-64109: Linux Kernel Use-After-Free Vulnerability

CVE-2026-64109 Overview

CVE-2026-64109 is a use-after-free (UAF) vulnerability in the Linux kernel's af_unix subsystem. The flaw resides in unix_stream_data_wait(), which calls skb_peek_tail(&sk->sk_receive_queue) without holding a lock that prevents concurrent dequeue and free of socket buffers (SKBs). A local attacker running two racing threads against the same UNIX stream socket can trigger a UAF read of tail->len after another thread frees the SKB via consume_skb(). The bug was introduced by commit 2b514574f7e8 ("net: af_unix: implement splice for stream af_unix sockets") and affects kernels from 6.5 onward.

Critical Impact
Local attackers can trigger a kernel-level use-after-free via a race between peeking and normal recv() calls on a UNIX stream socket, potentially leading to memory corruption, privilege escalation, or denial of service.

Affected Products

Linux kernel versions from 6.5 onward containing commit 2b514574f7e8
Distributions shipping affected mainline and stable kernels
Systems using AF_UNIXSOCK_STREAM sockets with SO_PEEK_OFF

Discovery Timeline

2026-07-19 - CVE-2026-64109 published to NVD
2026-07-20 - Last updated in NVD database

Technical Details for CVE-2026-64109

Vulnerability Analysis

The vulnerability affects the unix_stream_data_wait() function in the Linux kernel's af_unix implementation. This function is invoked when a receiver blocks waiting for new data on a UNIX stream socket. It calls skb_peek_tail() on the socket's receive queue to obtain the tail SKB, then compares it against the previously observed last SKB and reads tail->len to detect whether new data has been appended.

The function does not hold the receive queue spinlock during this operation. Another thread performing a normal recv() can concurrently call __skb_unlink() and consume_skb(), freeing the SKB while unix_stream_data_wait() still holds a stale pointer. The subsequent dereference of tail->len reads freed memory.

Root Cause

The root cause is a missing lock around skb_peek_tail(&sk->sk_receive_queue) in unix_stream_data_wait(). Commit 79f632c71bea introduced the tail peek pattern, and commit 2b514574f7e8 (splice support) turned an existing pointer comparison into a full dereference. Additionally, the historical rationale for checking tail->len \—\ appending data to the last SKB via sendpage() \—\ no longer applies after commits a0dbf5f818f9 (MSG_SPLICE_PAGES support) and 57d44a354a43 (converting unix_stream_sendpage() to MSG_SPLICE_PAGES). Data is now always placed into a new SKB, so tail->len cannot grow and the check is obsolete.

Attack Vector

Exploitation requires local access and the ability to open a UNIX socket pair. An attacker sets SO_PEEK_OFF on the receiver, then races two threads: one performing recv() with MSG_PEEK and one performing a normal recv() followed by shutdown(). The proof-of-concept scenario in the upstream commit message shows the peeking thread entering unix_stream_data_wait() and dereferencing tail->len after the second thread unlinks and frees the SKB under sk_receive_queue.lock. Successful exploitation depends on winning the race window between skb_peek_tail() and the tail->len read.

The upstream fix removes the read of tail->len entirely, since SKBs in the UNIX receive queue can no longer grow. The relevant commits are available in the Linux kernel stable tree (kernel.org commit be309f8e and related backports).

Detection Methods for CVE-2026-64109

Indicators of Compromise

Kernel oops or KASAN reports referencing unix_stream_data_wait, skb_peek_tail, or unix_stream_read_generic in the call stack
Unexpected process crashes or kernel panics on hosts with heavy UNIX socket use
Unprivileged processes repeatedly invoking recv() with MSG_PEEK on sockets configured with SO_PEEK_OFF

Detection Strategies

Enable KASAN (Kernel Address Sanitizer) on test kernels to surface UAF reads on sk_buff structures allocated via skbuff_head_cache
Audit installed kernel versions against the fix commits 26342087, 38bccb92, 5f162f95, acdff990, and be309f8e in the stable tree
Correlate dmesg output for BUG: KASAN: slab-use-after-free entries in unix_stream_data_wait across the fleet

Monitoring Recommendations

Monitor kernel logs for oops signatures and slab corruption warnings involving UNIX socket call paths
Track processes making repeated setsockopt(SO_PEEK_OFF) calls followed by concurrent MSG_PEEK receives on the same socket
Alert on unexpected kernel version drift on production hosts where patches have not been rolled out

How to Mitigate CVE-2026-64109

Immediate Actions Required

Apply the upstream fix that removes the tail->len read from unix_stream_data_wait() via distribution kernel updates
Prioritize patching hosts running kernels 6.5 and later that expose UNIX sockets to untrusted local users
Restrict local shell and container access on affected hosts until patched kernels are deployed

Patch Information

The fix is available in the Linux stable tree across multiple branches. Relevant commits include kernel.org commit 26342087, kernel.org commit 38bccb92, kernel.org commit 5f162f95, kernel.org commit acdff990, and kernel.org commit be309f8e. Upstream maintainers note the fix is not applicable to kernels before 6.5.

Workarounds

Reduce local attack surface by tightening access controls on multi-tenant systems and containers
Use seccomp filters to restrict setsockopt with SO_PEEK_OFF where application workloads do not require it
Deploy KASAN-enabled kernels in staging to detect exploitation attempts before pushing patched kernels to production

bash

# Verify running kernel version and check for fix inclusion
uname -r

# On Debian/Ubuntu, update to a patched kernel package
sudo apt update && sudo apt install --only-upgrade linux-image-$(uname -r | sed 's/-generic//')

# On RHEL/Fedora derivatives
sudo dnf update kernel

# Reboot to load the patched kernel
sudo systemctl reboot