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.

https://git.kernel.org/stable/c/26342087fac93b3932e6af61dc91ec029cb8a623

https://git.kernel.org/stable/c/38bccb927d83d7d52e5b20015a172a0b6101d11e

https://git.kernel.org/stable/c/5f162f95a95834f06a8ec6140889272ad12e842f

https://git.kernel.org/stable/c/acdff9907478e82208475b1151700d0b71dcdc63

https://git.kernel.org/stable/c/be309f8eae8b474a4a617eaae01324da996fc719

[{"vendor":"Linux","product":"Linux","defaultStatus":"unaffected","programFiles":["net/unix/af_unix.c"],"repo":"https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git","versions":[{"version":"2b514574f7e88c8498027ee366fd6e7aae5aa4b5","lessThan":"26342087fac93b3932e6af61dc91ec029cb8a623","versionType":"git","status":"affected"},{"version":"2b514574f7e88c8498027ee366fd6e7aae5aa4b5","lessThan":"38bccb927d83d7d52e5b20015a172a0b6101d11e","versionType":"git","status":"affected"},{"version":"2b514574f7e88c8498027ee366fd6e7aae5aa4b5","lessThan":"acdff9907478e82208475b1151700d0b71dcdc63","versionType":"git","status":"affected"},{"version":"2b514574f7e88c8498027ee366fd6e7aae5aa4b5","lessThan":"5f162f95a95834f06a8ec6140889272ad12e842f","versionType":"git","status":"affected"},{"version":"2b514574f7e88c8498027ee366fd6e7aae5aa4b5","lessThan":"be309f8eae8b474a4a617eaae01324da996fc719","versionType":"git","status":"affected"}]},{"vendor":"Linux","product":"Linux","defaultStatus":"affected","programFiles":["net/unix/af_unix.c"],"repo":"https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git","versions":[{"version":"4.2","status":"affected"},{"version":"0","lessThan":"4.2","versionType":"semver","status":"unaffected"},{"version":"6.6.143","lessThanOrEqual":"6.6.*","versionType":"semver","status":"unaffected"},{"version":"6.12.92","lessThanOrEqual":"6.12.*","versionType":"semver","status":"unaffected"},{"version":"6.18.34","lessThanOrEqual":"6.18.*","versionType":"semver","status":"unaffected"},{"version":"7.0.11","lessThanOrEqual":"7.0.*","versionType":"semver","status":"unaffected"},{"version":"7.1","lessThanOrEqual":"*","versionType":"original_commit_for_fix","status":"unaffected"}]}]