CVE-2026-23394

Linux nüvəsində aşağıdakı zəiflik aradan qaldırılıb: af_unix: MSG_PEEK müdaxilə etdikdə GC-dən imtina edin. İgor Ushakov yaxşı bir reproduksiya ilə bildirib ki, MSG_PEEK ilə yaranan yarış (race condition) səbəbindən GC aktiv soketin qəbul növbəsini təmizləyir. Bu, əvvəllər cbcf01128d0a ("af_unix: fix garbage collect vs MSG_PEEK") commit-i ilə düzəldilmiş eyni problemdir. GC cari alqoritmlə əvəz edildikdən sonra, qeyd olunan commit unix_peek_fds()-dəki kilidləmə mexanizmini silmiş və eyni problemi yenidən ortaya çıxarmışdır. Problem ondadır ki, MSG_PEEK, GC ilə qarşılıqlı əlaqədə olmadan faylın istinad sayını (refcount) artırır. sk-A və sk-B-ni ehtiva edən bir SCC-ni nəzərə alın, burada sk-A close() edilib, lakin sk-B vasitəsilə recv() edilə bilər. Pis hal ondan ibarətdir ki, GC sk-A və sk-B üçün unix_vertex_dead() funksiyasını yoxlayarkən, sk-A, sk-B-dən MSG_PEEK ilə recv() edilir və sk-B close() olunur. GC thread User thread --------- ----------- unix_vertex_dead(sk-A) -> true <------. \ `------ recv(sk-B, MSG_PEEK) invalidate !! -> sk-A'nin fayl refcount-u : 1 -> 2 close(sk-B) -> sk-B-nin fayl refcount-u : 2 -> 1 unix_vertex_dead(sk-B) -> true Başlanğıcda, sk-A-nın fayl refcount-u sk-B-nin recvq-sındakı uçuşdakı (inflight) fd səbəbindən 1-dir. GC elə hesab edir ki, sk-A ölüdür, çünki fayl refcount-u onun uçuşdakı fd-lərinin sayı ilə eynidir. Lakin, sk-A-nın fayl refcount-u MSG_PEEK tərəfindən səssiz şəkildə artırılır ki, bu da əvvəlki qiymətləndirməni etibarsız edir. Bu anda sk-B-nin fayl refcount-u 2-dir; biri açıq fd tərəfindən, digəri isə sk-A-dakı uçuşdakı fd tərəfindən. Sonrakı close() birinci refcount-u azaldır. Nəticədə, GC yanlış şəkildə həm sk-A, həm də sk-B-nin öldüyü qənaətinə gəlir. Variantlardan biri unix_peek_fds()-də kilidləmə mexanizmini bərpa etməkdir, lakin yeni alqoritm sayəsində bunu daha səmərəli şəkildə həll edə bilərik. Məqsəd odur ki, sonrakı close() olmadan problem baş vermir və bizə əslində MSG_PEEK-i ölü SCC aşkarlanması ilə sinxronlaşdırmaq lazım deyil. Problem baş verdikdə, close() və GC eyni fayl refcount-una toxunurlar. Əgər GC refcount-un close() tərəfindən azaldıldığını görərsə, sadəcə SCC-nin zibil yığımı (garbage collection) prosesindən imtina edə bilər. Buna görə də, biz yalnız MSG_PEEK zamanı yaranan yarışı uyğun yaddaş baryeri (memory barrier) ilə siqnallaşdırmalıyıq ki, bu, GC üçün görünən olsun. MSG_PEEK baş verdikdə GC-ni məlumatlandırmaq üçün seqcount_t-dən istifadə edək və onun SCC-ni növbəti işəmaçmaya təxirə salmasına şərait yaradaq. Beləliklə, MSG_PEEK tərəfində heç bir kilidləmə tələb olunmur və biz hər MSG_PEEK çağırışına lazımsız yerə yük düşməsinin qarşısını ala bilirik. Qeyd edək ki, MSG_PEEK aşkarlandıqda unix_scc_dead() daxilində yenidən cəhd edə bilərik, lakin sui-istifadə edilmiş MSG_PEEK çağırışları səbəbindən "hung task" xətalarının qarşısını almaq üçün bunu etmirik.