UBUNTU-CVE-2026-64109: Low severity ubuntu/linux-aws vulnerability

In the Linux kernel, the following vulnerability has been resolved: afunix: Fix UAF read of tail->len in unixstreamdatawait() unixstreamdatawait() does skbpeektail(&sk->skreceivequeue) 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 unixstreamdatawait() 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: afunix: implement splice for stream afunix sockets"), tail is actually dereferenced, which can cause UAF in the following race scenario (where testsetup() runs single-threaded, and afterwards, testthread1() and testthread2() run concurrently in two threads: static int socks[2]; void testsetup(void) { socketpair(AFUNIX, SOCKSTREAM, 0, socks); send(socks[1], "A", 1, 0); int peekoff = 1; setsockopt(socks[0], SOLSOCKET, SOPEEKOFF, &peekoff, sizeof(peekoff)); } void testthread1(void) { char dummy; recv(socks[0], &dummy, 1, MSGPEEK); } void testthread2(void) { char dummy; recv(socks[0], &dummy, 1, 0); shutdown(socks[1], SHUTWR); } when racing like this: thread1 thread2 unixstreamreadgeneric mutexlock(&u->iolock) skbpeek(&sk->skreceivequeue) skbpeeknext(skb, &sk->skreceivequeue) mutexunlock(&u->iolock) unixstreamreadgeneric unixstatelock(sk) skbpeek(&sk->skreceivequeue) unixstateunlock(sk) unixstreamdatawait unixstatelock(sk) tail = skbpeektail(&sk->skreceivequeue) spinlock(&sk->skreceivequeue.lock) skbunlink(skb, &sk->skreceivequeue) spinunlock(&sk->skreceivequeue.lock) consumeskb(skb) [frees the SKB] tail != last: false tail: true tail->len != lastlen 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: afunix: 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 unixstreamdatawait(). > > However, commit a0dbf5f818f9 ("afunix: Support MSGSPLICEPAGES") and > commit 57d44a354a43 ("unix: Convert unixstreamsendpage() to use > MSGSPLICEPAGES") refactored sendmsg(), and now data is always added > to a new skb. That means this fix is not suitable for kernels before 6.5.