CVE-2026-64109

Linux kernel içerisinde aşağıdaki güvenlik açığı giderilmiştir: af_unix: unix_stream_data_wait() fonksiyonundaki tail->len serbest bırakıldıktan sonra kullanım (UAF) okuması düzeltildi unix_stream_data_wait(), söz konusu kuyruktaki SKB'lerin kuyruktan çıkarılmasını ve serbest bırakılmasını önleyen herhangi bir kilit tutmadan skb_peek_tail(&sk->sk_receive_queue) işlemini gerçekleştirmektedir. Bu durum, 79f632c71bea ("unix/stream: fix peeking with an offset larger than data in queue") commit'inden beri mevcuttur. Bunun ilk sonucu, `last` anlamsal olarak zaten serbest bırakılmış bir SKB'ye referans verirken `tail` aynı adreste tahsis edilmiş yeni bir SKB olduğunda bile `tail != last` işaretçi karşılaştırmasının yanlış olabilmesidir; bu da unix_stream_data_wait()'in yeni veri geldikten sonra hatalı bir şekilde bloklamaya devam etmesine neden olabilir, ancak bu yalnızca aynı soket üzerinde bir peeking recv() ve normal bir recv()'nin yarıştığı nadir bir senaryoda gerçekleşir ve muhtemelen gerçek bir sorun değildir. Ancak 2b514574f7e8 ("net: af_unix: implement splice for stream af_unix sockets") commit'inden itibaren `tail` aslında dereference edilmektedir, bu da aşağıdaki yarış senaryosunda (test_setup() tek iş parçacıklı çalışır ve ardından test_thread1() ile test_thread2() iki ayrı iş parçacığında eşzamanlı olarak çalışır) UAF'ye neden olabilir: ``` 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); } ``` Şu şekilde yarıştıklarında: ``` 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) [SKB'yi serbest bırakır] `tail != last`: false `tail`: true `tail->len != last_len` ***UAF*** ``` tail->len okuması kaldırılarak UAF düzeltilmiştir; tail->len kontrolü yalnızca bir UNIX soketinin alma kuyruğundaki SKB'ler büyüyebilseydi anlamlı olurdu, ancak bu artık mümkün değildir. Kuniyuki şöyle açıklamıştır: > 869e7c62486e ("net: af_unix: implement stream sendpage support") commit'i sendpage() desteği eklediğinde, alıcının kuyruğundaki son skb'ye veri eklenebiliyordu. > > Bu nedenle, unix_stream_data_wait() içinde yeni veri beklenirken son skb uzunluğunun değişip değişmediğini kontrol etmemiz gerekiyordu. > > Ancak, a0dbf5f818f9 ("af_unix: Support MSG_SPLICE_PAGES") ve 57d44a354a43 ("unix: Convert unix_stream_sendpage() to use MSG_SPLICE_PAGES") commit'leri sendmsg() fonksiyonunu yeniden yapılandırdı ve artık veriler her zaman yeni bir skb'ye ekleniyor. Bu, söz konusu düzeltmenin 6.5 öncesindeki kernellar için uygun olmadığı anlamına gelmektedir.