CVE-2026-64109af_unix: Fix UAF read of tail->len in unix_stream_data_wait()

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.

Timeline

Scores

EPSS (exploitation in 30 days)

0.13% · top 97% of all CVEs (12 Nov 2026)

CISA SSVC

Exploitation: none · Automatable: no · Technical impact: total

The list uses the assigner's score when there is one, then CISA's, then NVD's: High 8.8.

Affected products

• Linux · Linux

  • affected 2b514574f7e88c8498027ee366fd6e7aae5aa4b5 – < 26342087fac93b3932e6af61dc91ec029cb8a623
  • affected 2b514574f7e88c8498027ee366fd6e7aae5aa4b5 – < 38bccb927d83d7d52e5b20015a172a0b6101d11e
  • affected 2b514574f7e88c8498027ee366fd6e7aae5aa4b5 – < acdff9907478e82208475b1151700d0b71dcdc63
  • affected 2b514574f7e88c8498027ee366fd6e7aae5aa4b5 – < 5f162f95a95834f06a8ec6140889272ad12e842f
  • affected 2b514574f7e88c8498027ee366fd6e7aae5aa4b5 – < be309f8eae8b474a4a617eaae01324da996fc719

• Linux · Linux

  • affected 4.2
  • unaffected < 4.2
  • unaffected 6.6.143 – ≤ 6.6.*
  • unaffected 6.12.92 – ≤ 6.12.*
  • unaffected 6.18.34 – ≤ 6.18.*
  • unaffected 7.0.11 – ≤ 7.0.*
  • unaffected 7.1 – ≤ *

Sources

The same CVE in the primary databases and aggregators, to check against.

• CVE.org record (opens in a new tab)
• CVE List JSON (GitHub) (opens in a new tab)
• NVD (opens in a new tab)
• FIRST EPSS (opens in a new tab)
• EUVD EUVD-2026-45794 (opens in a new tab)
• OSV.dev (opens in a new tab)
• GitHub Advisories (opens in a new tab)
• CIRCL Vulnerability-Lookup (opens in a new tab)

Badge for a README or a ticket

[![CVE-2026-64109](https://cveledger.app/badge/CVE-2026-64109.svg)](https://cveledger.app/cve/CVE-2026-64109)

Record last updated 19 Oct 2026, 20:28 UTC.