CVE-2026-23394

Linux kernel içerisinde aşağıdaki güvenlik açığı giderilmiştir: af_unix: MSG_PEEK müdahale ettiyse GC işlemini iptal et. Igor Ushakov, MSG_PEEK ile yaşanan bir yarış durumu nedeniyle GC'nin canlı bir soketin alma kuyruğunu temizlediğini uygun bir yeniden üretim örneğiyle bildirmiştir. Bu durum, daha önce cbcf01128d0a ("af_unix: fix garbage collect vs MSG_PEEK") commit'i ile düzeltilen sorunla tamamen aynıdır. GC mevcut algoritmayla değiştirildikten sonra, söz konusu commit unix_peek_fds() içerisindeki kilitleme mekanizmasını kaldırmış ve aynı sorunu yeniden ortaya çıkarmıştır. Sorun, MSG_PEEK'in GC ile etkileşime girmeden bir dosya referans sayacını artırmasıdır. sk-A ve sk-B içeren, sk-A'nın close() edildiği ancak sk-B üzerinden recv() edilebildiği bir SCC düşünün. Kötü senaryo, sk-A'nın sk-B'den MSG_PEEK ile recv() edilmesi ve GC, sk-A ve sk-B için unix_vertex_dead() kontrolünü yaparken sk-B'nin close() edilmesi durumunda gerçekleşir. GC iş parçacığı Kullanıcı iş parçacığı --------- ----------- unix_vertex_dead(sk-A) -> doğru <------. \ `------ recv(sk-B, MSG_PEEK) geçersiz kılma !! -> sk-A'nın dosya referans sayısı : 1 -> 2 close(sk-B) -> sk-B'nin dosya referans sayısı : 2 -> 1 unix_vertex_dead(sk-B) -> doğru Başlangıçta, sk-A'nın dosya referans sayısı, sk-B recvq içindeki uçuşta olan fd nedeniyle 1'dir. GC, dosya referans sayısı uçuşta olan fd sayısı ile aynı olduğu için sk-A'nın ölü olduğunu düşünür. Ancak, sk-A'nın dosya referans sayısı MSG_PEEK tarafından sessizce artırılır ve bu da önceki değerlendirmeyi geçersiz kılar. Bu anda, sk-B'nin dosya referans sayısı 2'dir; biri açık fd'den, diğeri sk-A'daki uçuşta olan fd'den gelir. Ardından gelen close() işlemi, ilkinden kaynaklanan bir referans sayısını serbest bırakır. Sonuç olarak GC, hatalı bir şekilde hem sk-A'nın hem de sk-B'nin ölü olduğu sonucuna varır. Seçeneklerden biri unix_peek_fds() içindeki kilitleme mekanizmasını geri getirmektedir, ancak yeni algoritma sayesinde bunu daha zarif bir şekilde çözebiliriz. Buradaki nokta, ardışık close() işlemi olmadan sorunun oluşmamasıdır ve aslında MSG_PEEK'i ölü SCC tespitiyle senkronize etmemize gerek yoktur. Sorun oluştuğunda, close() ve GC aynı dosya referans sayısına dokunur. Eğer GC, referans sayısının close() tarafından azaltıldığını görürse, SCC'yi çöp toplamayı (garbage collection) basitçe bırakabilir. Bu nedenle, MSG_PEEK sırasındaki yarış durumunu, GC tarafından görünür kılmak için uygun bir bellek bariyeri ile işaretlememiz yeterlidir. MSG_PEEK gerçekleştiğinde GC'ye bildirmek için seqcount_t kullanalım ve SCC'yi bir sonraki çalışmaya ertelemesini sağlayalım. Bu sayede MSG_PEEK tarafında herhangi bir kilitlemeye gerek kalmaz ve her MSG_PEEK işlemine gereksiz yere performans kaybı yüklemekten kaçınmış oluruz. MSG_PEEK tespit edilirse unix_scc_dead() içinde tekrar deneme yapılabileceğini belirtelim, ancak kötü niyetli MSG_PEEK çağrılarından kaynaklanabilecek askıda kalan görev (hung task) hatalarını önlemek için bunu yapmıyoruz.