In the Linux kernel, the following vulnerability has been resolved:<\/p>\n
af_unix: Fix UAF read of tail->len in unix_stream_data_wait()<\/p>\n
unix_stream_data_wait() does skb_peek_tail(&sk->sk_receive_queue) without
\nholding any lock that prevents SKBs on that queue from being dequeued and
\nfreed.
\nThis has been the case since commit 79f632c71bea (“unix\/stream: fix
\npeeking with an offset larger than data in queue”).
\nThe first consequence of this is that the pointer comparison
\n`tail != last` can be false even if `last` semantically refers to an
\nalready-freed SKB while `tail` is a new SKB allocated at the same address;
\nwhich can cause unix_stream_data_wait() to wrongly keep blocking after new
\ndata has arrived, but only in a weird scenario where a peeking recv() and
\na normal recv() on the same socket are racing, which is probably not a
\nreal problem.<\/p>\n
But since commit 2b514574f7e8 (“net: af_unix: implement splice for stream
\naf_unix sockets”), `tail` is actually dereferenced, which can cause UAF in
\nthe following race scenario (where test_setup() runs single-threaded,
\nand afterwards, test_thread1() and test_thread2() run concurrently in
\ntwo threads:
\n“`
\nstatic int socks[2];
\nvoid test_setup(void) {
\n socketpair(AF_UNIX, SOCK_STREAM, 0, socks);
\n send(socks[1], “A”, 1, 0);
\n int peekoff = 1;
\n setsockopt(socks[0], SOL_SOCKET, SO_PEEK_OFF, &peekoff, sizeof(peekoff));
\n}
\nvoid test_thread1(void) {
\n char dummy;
\n recv(socks[0], &dummy, 1, MSG_PEEK);
\n}
\nvoid test_thread2(void) {
\n char dummy;
\n recv(socks[0], &dummy, 1, 0);
\n shutdown(socks[1], SHUT_WR);
\n}
\n“`<\/p>\n
when racing like this:
\n“`
\nthread1 thread2
\nunix_stream_read_generic
\n mutex_lock(&u->iolock)
\n skb_peek(&sk->sk_receive_queue)
\n skb_peek_next(skb, &sk->sk_receive_queue)
\n mutex_unlock(&u->iolock)
\n unix_stream_read_generic
\n unix_state_lock(sk)
\n skb_peek(&sk->sk_receive_queue)
\n unix_state_unlock(sk)
\n unix_stream_data_wait
\n unix_state_lock(sk)
\n tail = skb_peek_tail(&sk->sk_receive_queue)
\n spin_lock(&sk->sk_receive_queue.lock)
\n __skb_unlink(skb, &sk->sk_receive_queue)
\n spin_unlock(&sk->sk_receive_queue.lock)
\n consume_skb(skb) [frees the SKB]
\n `tail != last`: false
\n `tail`: true
\n `tail->len != last_len` ***UAF***
\n“`<\/p>\n
Fix the UAF by removing the read of tail->len; checking tail->len would
\nonly make sense if SKBs in the receive queue of a UNIX socket could grow,
\nwhich can no longer happen.<\/p>\n
Kuniyuki explained:<\/p>\n
> When commit 869e7c62486e (“net: af_unix: implement stream sendpage
\n> support”) added sendpage() support, data could be appended to the last
\n> skb in the receiver’s queue.
\n>
\n> That’s why we needed to check if the length of the last skb was changed
\n> while waiting for new data in unix_stream_data_wait().
\n>
\n> However, commit a0dbf5f818f9 (“af_unix: Support MSG_SPLICE_PAGES”) and
\n> commit 57d44a354a43 (“unix: Convert unix_stream_sendpage() to use
\n> MSG_SPLICE_PAGES”) refactored sendmsg(), and now data is always added
\n> to a new skb.<\/p>\n
That means this fix is not suitable for kernels before 6.5.<\/p>\n","protected":false},"excerpt":{"rendered":"
In the Linux kernel, the following vulnerability has been resolved:<\/p>\n
af_unix: Fix UAF read of tail->len in unix_stream_data_wait()<\/p>\n
unix_stream_data_wait() does skb_peek_tail(&sk->sk_receive_queue) wi<\/p>\n","protected":false},"template":"","meta":[],"categories":[],"tags":[],"class_list":["post-15079","vuln","type-vuln","status-publish","hentry"],"_links":{"self":[{"href":"https:\/\/www.54iter.cn\/index.php?rest_route=\/wp\/v2\/vuln\/15079","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.54iter.cn\/index.php?rest_route=\/wp\/v2\/vuln"}],"about":[{"href":"https:\/\/www.54iter.cn\/index.php?rest_route=\/wp\/v2\/types\/vuln"}],"wp:attachment":[{"href":"https:\/\/www.54iter.cn\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=15079"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.54iter.cn\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=15079"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.54iter.cn\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=15079"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}