Gzip 1.15, yanlış dosyayı silebilecek onlarca yıllık race condition hatasını gideriyor

GNU projesi 20 Eylül 2026'da gzip 1.15'i yayımladı ve çoğu durumda sıkıştırma aracının en eski günlerinden beri var olan bir dizi hatayı kapattı. Jim Meyering sürümü GNU info-gnu posta listesinde duyurdu. Manşetteki düzeltme, gzip'in hiç dokunmak niyetinde olmadığı bir dosyayı silmesine yol açabilecek bir race condition sorununu ortadan kaldırıyor.

Sürüm, 75 hafta boyunca yazılmış 119 commit'i bir araya getiriyor; bunların 88'ini Paul Eggert, 24'ünü Meyering yazdı, ayrıca Mark Adler, Bruno Haible ve Collin Funk'tan küçük katkılar geldi. Phoronix'e göre önceki sürüm olan gzip 1.14, Nisan 2025 tarihli.

Yanlış dosya silinmesi nasıl gerçekleşiyordu

Gzip'in standart iş akışı, bir dosyayı sıkıştırmak ve sıkıştırılmış çıktı güvenle yazıldıktan sonra orijinali kaldırmaktır. Hata bu son adımda, hangi dosyanın unlink edileceğinin belirlenmesindeydi.

Duyuruya göre, gzip işlem sırasındayken başka bir süreç gzip'in çıktı yolunun üzerindeki bir dizini yeniden adlandırırsa, gzip yolu ikinci kez çözebilir ve daha sonra sildiği farklı bir dosyaya ulaşabilir. Burada üst dizin, hedef dosyadan yukarıdaki yoldaki herhangi bir dizini ifade ediyor.

Arıza iki bağımsız programın zamanlamasına bağlı olduğundan kesin bir tesadüf gerektiriyor ve bu yüzden nadir görülüyor. Ancak eşzamanlı otomasyon çalıştıran yoğun sunucularda nadir, asla anlamına gelmiyor; Tech AI Wire, sürüm klasörlerini yerlerine değiştiren dağıtım betiklerini klasik tetikleyici olarak gösteriyor: bu betikler, içinde hâlâ çalışan süreçlerin olduğu dizinleri yeniden adlandırıyor.

İkinci bir senkronizasyon düzeltmesi, O_PATH veya O_SEARCH bayraklarını destekleyen sistemlerdeki kilitleme hatalarını ele alıyor. Bu hata diğerlerinden daha yeni ve gzip 1.7 ile gelmişti.

.lzh çözücüsündeki bellek güvenliği düzeltmeleri

Düzeltmelerin üçü, gzip'in .lzh dosyaları — Japonya'da yoğun biçimde kullanılmış eski bir sıkıştırma biçimi — çözücüsünü hedefliyor. Duyuruya göre bir .Z dosyasını açtıktan sonra bir .lzh dosyası açılırken ulaşılabilen bir buffer overflow söz konusu; yani program, ayırdığı belleğin sonunun ötesine yazabiliyordu.

İki ek .lzh kusuru çökme yerine bozuk çıktı üretiyordu: bir .lzh dosyasını diğerinden sonra açmak, önceki dosyadan kalan eski bir çözümleme tablosunu yeniden kullanabiliyordu ve dahili bir bit tamponu temizlenmemiş kalabiliyordu. Ayrıca gzip, bazı bozuk girdilerde başlatılmamış belleği okuyabiliyordu. Duyuru, bu sorunların hiçbiri için CVE tanımlayıcısı listelemiyor.

Davranış değişiklikleri ve bırakılan platformlar

Birkaç değişiklik hata onarmak yerine davranışı değiştiriyor ve bazıları yükseltmeden önce hızlıca gözden geçirilmeyi hak ediyor:

• Gzip artık C locale'unu varsaymak yerine ortamın locale'unu izliyor; bu, dosya adlarının makineler arasında nasıl sıralanacağını veya raporlanacağını değiştirebilir.

• Boş bir dosyayı sıkıştırmak artık 0.0% yerine -Inf% oranı bildiriyor; bu, oranı düz bir sayı olarak ayrıştıran her betiği kırar.

• znew -P seçeneği artık yok sayılıyor ve bir uyarı basıyor.

• Tanı mesajları artık olağan dışı karakterler içeren dosya adlarını tırnak içine alıyor.

• gzip -d artık PKZIP imzalarını, local header'ları ve data descriptor'ları kabul ediyor.

FreeBSD 4.11 ve öncesi, HP-UX 11.00, Minix 3.1.8 ve UCRT olmadan MinGW üzerinden yapılan Windows 8.1 derlemeleri için destek bırakıldı. gzexe, zdiff ve znew yardımcı betiklerindeki geçici dosyalarla ilgili race condition sorunları da giderildi.

Neden önemli

Gzip, neredeyse her Linux ve Unix sisteminde gelen .gz dosyalarının arkasındaki motordur ve paket yöneticilerine, yedekleme işlerine ve log rotasyonuna kabloludur. Bu kadar göze çarpmayan ama her yerde bulunan bu tür bir altyapıdaki bir kusur, görünümünün ima ettiğinden çok daha fazla makineye ulaşır ve bu hataların üzerinde onlarca yıldır betikler çalışıyor.

Silme race condition'ı yalnızca bir çökme değil, veri kaybı hatasıdır: tetiklendiğinde yanlış dosya gider. Çözücü düzeltmeleri de dikkati hak ediyor. CVE tanımlayıcısı olmasa da ikisi bellek güvenliği hatasıdır ve saldırgan tarafından sağlanan arşivleri gzip'e besleyen her hizmet, o çözücüyü güvenilmeyen girdiye maruz bırakır. Pratik kontrol listesi kısa: yamalayın, gzip'in oran çıktısını ayrıştıran veya locale-stabil dosya adı işlemeye güvenen her şeyi kontrol edin, çalışan işlerin altında dizinleri yeniden adlandıran dağıtım betiklerini gözden geçirin ve derleme hedeflerinizin bırakılan platformlar arasında olmadığını doğrulayın.