In the Linux kernel, the following vulnerability has been resolved: af_unix: Fix UAF read of tail->len in unix_stream_data_wait()… (CVE-2026-64109)
In the Linux kernel, the following vulnerability has been resolved: af_unix: Fix UAF read of tail->len in unix_stream_data_wait() unix_stream_data_wait() does skb_peek_tail(&sk->sk_receive_queue) without holding any lock that prevents SKBs on that queue from being dequeued and freed. This has been the case since commit 79f632c71bea ("unix/stream: fix peeking with an offset larger than data in queue"). The first consequence of this is that the pointer comparison `tail != last` can be false even if `last` semantically refers to an already-freed SKB while `tail` is a new SKB allocated at the same address; which can cause unix_stream_data_wait() to wrongly keep blocking after new data has arrived, but only in a weird scenario where a peeking recv() and a normal recv() on the same socket are racing, which is probably not a real problem. But since commit 2b514574f7e8 ("net: af_unix: implement splice for stream af_unix sockets"), `tail` is actually dereferenced, which can cause UAF in the following race scenario (where test_setup() runs single-threaded, and afterwards, test_thread1() and test_thread2() run concurrently in two threads: ``` static int socks[2]; void test_setup(void) { socketpair(AF_UNIX, SOCK_STREAM, 0, socks); send(socks[1], "A", 1, 0); int peekoff = 1; setsockopt(socks[0], SOL_SOCKET, SO_PEEK_OFF, &peekoff, sizeof(peekoff)); } void test_thread1(void) { char dummy; recv(socks[0], &dummy, 1, MSG_PEEK); } void test_thread2(void) { char dummy; recv(socks[0], &dummy, 1, 0); shutdown(socks[1], SHUT_WR); } ``` when racing like this: ``` thread1 thread2 unix_stream_read_generic mutex_lock(&u->iolock) skb_peek(&sk->sk_receive_queue) skb_peek_next(skb, &sk->sk_receive_queue) mutex_unlock(&u->iolock) unix_stream_read_generic unix_state_lock(sk) skb_peek(&sk->sk_receive_queue) unix_state_unlock(sk) unix_stream_data_wait unix_state_lock(sk) tail = skb_peek_tail(&sk->sk_receive_queue) spin_lock(&sk->sk_receive_queue.lock) __skb_unlink(skb, &sk->sk_receive_queue) spin_unlock(&sk->sk_receive_queue.lock) consume_skb(skb) [frees the SKB] `tail != last`: false `tail`: true `tail->len != last_len` ***UAF*** ``` Fix the UAF by removing the read of tail->len; checking tail->len would only make sense if SKBs in the receive queue of a UNIX socket could grow, which can no longer happen. Kuniyuki explained: > When commit 869e7c62486e ("net: af_unix: implement stream sendpage > support") added sendpage() support, data could be appended to the last > skb in the receiver's queue. > > That's why we needed to check if the length of the last skb was changed > while waiting for new data in unix_stream_data_wait(). > > However, commit a0dbf5f818f9 ("af_unix: Support MSG_SPLICE_PAGES") and > commit 57d44a354a43 ("unix: Convert unix_stream_sendpage() to use > MSG_SPLICE_PAGES") refactored sendmsg(), and now data is always added > to a new skb. That means this fix is not suitable for kernels before 6.5.
AI Analysis
Technical Summary
The vulnerability CVE-2026-64109 is a use-after-free (UAF) in the Linux kernel's AF_UNIX socket code, specifically in unix_stream_data_wait(). The function performs skb_peek_tail() without holding a lock that prevents SKBs from being dequeued and freed, leading to a race condition where a pointer to a freed SKB is dereferenced. This occurs when a peeking recv() and a normal recv() race on the same socket, causing tail->len to be read after the SKB is freed. The root cause is that data is now always added to new SKBs rather than appended to the last SKB, making the tail->len check obsolete. The fix removes the read of tail->len to prevent UAF. This fix applies to kernels 6.5 and later, as earlier kernels do not have the relevant code paths.
Potential Impact
The impact is a use-after-free vulnerability in the Linux kernel AF_UNIX socket implementation, which could lead to kernel memory corruption or instability if exploited. However, the vulnerability requires a specific race condition involving concurrent recv() calls on the same socket with and without MSG_PEEK, which is a relatively unusual scenario. There are no known exploits in the wild. The vulnerability affects kernel versions 6.5 and later due to the code changes involved.
Mitigation Recommendations
A fix for this vulnerability is available and has been applied in Linux kernel version 6.5 and later. Users should upgrade to kernel version 6.5 or later to mitigate this issue. Since this is a kernel-level vulnerability, applying the official kernel update is the recommended remediation. No additional mitigation steps are indicated by the vendor advisory.
In the Linux kernel, the following vulnerability has been resolved: af_unix: Fix UAF read of tail->len in unix_stream_data_wait()… (CVE-2026-64109)
Description
In the Linux kernel, the following vulnerability has been resolved: af_unix: Fix UAF read of tail->len in unix_stream_data_wait() unix_stream_data_wait() does skb_peek_tail(&sk->sk_receive_queue) without holding any lock that prevents SKBs on that queue from being dequeued and freed. This has been the case since commit 79f632c71bea ("unix/stream: fix peeking with an offset larger than data in queue"). The first consequence of this is that the pointer comparison `tail != last` can be false even if `last` semantically refers to an already-freed SKB while `tail` is a new SKB allocated at the same address; which can cause unix_stream_data_wait() to wrongly keep blocking after new data has arrived, but only in a weird scenario where a peeking recv() and a normal recv() on the same socket are racing, which is probably not a real problem. But since commit 2b514574f7e8 ("net: af_unix: implement splice for stream af_unix sockets"), `tail` is actually dereferenced, which can cause UAF in the following race scenario (where test_setup() runs single-threaded, and afterwards, test_thread1() and test_thread2() run concurrently in two threads: ``` static int socks[2]; void test_setup(void) { socketpair(AF_UNIX, SOCK_STREAM, 0, socks); send(socks[1], "A", 1, 0); int peekoff = 1; setsockopt(socks[0], SOL_SOCKET, SO_PEEK_OFF, &peekoff, sizeof(peekoff)); } void test_thread1(void) { char dummy; recv(socks[0], &dummy, 1, MSG_PEEK); } void test_thread2(void) { char dummy; recv(socks[0], &dummy, 1, 0); shutdown(socks[1], SHUT_WR); } ``` when racing like this: ``` thread1 thread2 unix_stream_read_generic mutex_lock(&u->iolock) skb_peek(&sk->sk_receive_queue) skb_peek_next(skb, &sk->sk_receive_queue) mutex_unlock(&u->iolock) unix_stream_read_generic unix_state_lock(sk) skb_peek(&sk->sk_receive_queue) unix_state_unlock(sk) unix_stream_data_wait unix_state_lock(sk) tail = skb_peek_tail(&sk->sk_receive_queue) spin_lock(&sk->sk_receive_queue.lock) __skb_unlink(skb, &sk->sk_receive_queue) spin_unlock(&sk->sk_receive_queue.lock) consume_skb(skb) [frees the SKB] `tail != last`: false `tail`: true `tail->len != last_len` ***UAF*** ``` Fix the UAF by removing the read of tail->len; checking tail->len would only make sense if SKBs in the receive queue of a UNIX socket could grow, which can no longer happen. Kuniyuki explained: > When commit 869e7c62486e ("net: af_unix: implement stream sendpage > support") added sendpage() support, data could be appended to the last > skb in the receiver's queue. > > That's why we needed to check if the length of the last skb was changed > while waiting for new data in unix_stream_data_wait(). > > However, commit a0dbf5f818f9 ("af_unix: Support MSG_SPLICE_PAGES") and > commit 57d44a354a43 ("unix: Convert unix_stream_sendpage() to use > MSG_SPLICE_PAGES") refactored sendmsg(), and now data is always added > to a new skb. That means this fix is not suitable for kernels before 6.5.
CVSS v3.1
AI-Powered Analysis
Machine-generated threat intelligence
Technical Analysis
The vulnerability CVE-2026-64109 is a use-after-free (UAF) in the Linux kernel's AF_UNIX socket code, specifically in unix_stream_data_wait(). The function performs skb_peek_tail() without holding a lock that prevents SKBs from being dequeued and freed, leading to a race condition where a pointer to a freed SKB is dereferenced. This occurs when a peeking recv() and a normal recv() race on the same socket, causing tail->len to be read after the SKB is freed. The root cause is that data is now always added to new SKBs rather than appended to the last SKB, making the tail->len check obsolete. The fix removes the read of tail->len to prevent UAF. This fix applies to kernels 6.5 and later, as earlier kernels do not have the relevant code paths.
Potential Impact
The impact is a use-after-free vulnerability in the Linux kernel AF_UNIX socket implementation, which could lead to kernel memory corruption or instability if exploited. However, the vulnerability requires a specific race condition involving concurrent recv() calls on the same socket with and without MSG_PEEK, which is a relatively unusual scenario. There are no known exploits in the wild. The vulnerability affects kernel versions 6.5 and later due to the code changes involved.
Mitigation Recommendations
A fix for this vulnerability is available and has been applied in Linux kernel version 6.5 and later. Users should upgrade to kernel version 6.5 or later to mitigate this issue. Since this is a kernel-level vulnerability, applying the official kernel update is the recommended remediation. No additional mitigation steps are indicated by the vendor advisory.
Technical Details
- Gcve Source
- db.gcve.eu
- Osv Id
- GHSA-mh36-g5h5-fxqc
- Osv Schema Version
- 1.4.0
- Aliases
- ["CVE-2026-64109"]
- Ecosystems
- []
- Database Specific Severity
- null
- Cvss Version
- null
Threat ID: 6a5d27a82a4a8d598912b55e
Added to database: 07/19/2026, 19:38:16 UTC
Last enriched: 07/19/2026, 19:47:41 UTC
Last updated: 07/20/2026, 19:41:21 UTC
Views: 11
Community Reviews
0 reviewsCrowdsource mitigation strategies, share intel context, and vote on the most helpful responses. Sign in to add your voice and help keep defenders ahead.
Want to contribute mitigation steps or threat intel context? Sign in or create an account to join the community discussion.
Actions
Updates to AI analysis require Pro Console access. Upgrade inside Console → Billing.
Need more coverage?
Upgrade to Pro Console for AI refresh and higher limits.
For incident response and remediation, OffSeq services can help resolve threats faster.
Latest Threats
Check if your credentials are on the dark web
Instant breach scanning across billions of leaked records. Free tier available.