CVE-2026-64109

Linux nüvəsində aşağıdakı zəiflik aradan qaldırılıb: af_unix: unix_stream_data_wait() funksiyasında tail->len dəyişəninin UAF oxunuşu düzəldildi unix_stream_data_wait() funksiyası, həmin növbədəki SKB-lərin növbədən çıxarılmasının və azad edilməsinin qarşısını alan heç bir kilidi saxlamadan skb_peek_tail(&sk->sk_receive_queue) əməliyyatını yerinə yetirir. Bu vəziyyət 79f632c71bea ("unix/stream: fix peeking with an offset larger than data in queue") commit-indən bəri mövcuddur. Bunun ilk nəticəsi odur ki, `last` semantik olaraq artıq azad edilmiş SKB-yə istinad etdikdə və `tail` eyni ünvanda ayrılmış yeni SKB olduqda, `tail != last` göstəricilərinin müqayisəsi yanlış şəkildə yalan (false) ola bilər; bu isə yeni məlumat gəldikdən sonra belə unix_stream_data_wait()-in səhvən bloklanmağa davam etməsinə səbəb ola bilər, lakin bu yalnız eyni soket üzərində peeking recv() və normal recv() yarışdıqda baş verən nadir ssenaridə mümkündür və çox güman ki, real problem deyil. Lakin 2b514574f7e8 ("net: af_unix: implement splice for stream af_unix sockets") commit-indən sonra `tail` faktiki olaraq dereference edilir ki, bu da aşağıdakı yarış ssenarisində UAF-a səbəb ola bilər (burada test_setup() tək axınlı işləyir, daha sonra test_thread1() və test_thread2() iki ayrı axında eyni vaxtda işləyir): ``` 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); } ``` Belə bir yarış zamanı: ``` 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-ni azad edir] `tail != last`: false `tail`: true `tail->len != last_len` ***UAF*** ``` tail->len oxunması silinərək UAF aradan qaldırıldı; tail->len yoxlaması yalnız UNIX soketinin qəbul növbəsindəki SKB-lər böyüyə bildiyi halda məna kəsb edərdi, lakin artıq bu mümkün deyil. Kuniyuki izah etmişdir: > 869e7c62486e ("net: af_unix: implement stream sendpage support") commit-i sendpage() dəstəyini əlavə etdikdə, qəbulçunun növbəsindəki sonuncu skb-yə məlumatlar əlavə edilə bilirdi. > > Məhz buna görə də unix_stream_data_wait()-də yeni məlumat gözləyərkən sonuncu skb-nin uzunluğunun dəyişib-dəyişmədiyini yoxlamağımız lazım idi. > > Lakin a0dbf5f818f9 ("af_unix: Support MSG_SPLICE_PAGES") və 57d44a354a43 ("unix: Convert unix_stream_sendpage() to use MSG_SPLICE_PAGES") commit-ləri sendmsg() funksiyasını yenidən strukturlaşdırdı və indi məlumatlar hər zaman yeni skb-yə əlavə olunur. Bu o deməkdir ki, bu düzəliş 6.5 versiyasından əvvəlki nüvələr üçün uyğun deyil.