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.

An update of the linux package has been released.

The Linux/Unix host has one or more packages installed that are impacted by a vulnerability without a vendor supplied patch available.

  - 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. (CVE-2026-64109)

Note that Nessus relies on the presence of the package as reported by the vendor.

ID	Name	Product	Family	Type	Severity
340681	Ubuntu 24.04 LTS / 26.04 LTS / Pro Realtime 24.04 LTS : Linux kernel (NVIDIA) vulnerabilities (USN-8663-1)	Nessus	Ubuntu Local Security Checks	Local	high
340045	Ubuntu 26.04 LTS : Linux kernel (NVIDIA BaseOS) vulnerabilities (USN-8664-1)	Nessus	Ubuntu Local Security Checks	Local	high
333944	Photon OS 5.0: Linux PHSA-2026-5.0-92-0864	Nessus	PhotonOS Local Security Checks	Local	high
327908	Linux Distros Unpatched Vulnerability : CVE-2026-64109	Nessus	Misc.	Local	high
322107	Amazon Linux 2023 : bpftool6.12, kernel6.12, kernel6.12-devel (ALAS2023-2026-1894)	Nessus	Amazon Linux Local Security Checks	Local	high
322087	Amazon Linux 2023 : bpftool6.18, kernel6.18, kernel6.18-devel (ALAS2023-2026-1881)	Nessus	Amazon Linux Local Security Checks	Local	high
318773	Photon OS 5.0: Linux PHSA-2026-5.0-0864	Nessus	PhotonOS Local Security Checks	Local	high

Detections

Analytics

CVE-2026-64109

high

Tenable Plugins

high

high

high

high

high

high

high