7 Temmuz 2026’da CVE-2026-43499 için çalışan bir istismar kodu kamuoyuyla paylaşıldı. GhostLock olarak adlandırılan bu açık, ayrıcalıksız herhangi bir yerel kullanıcının yaklaşık beş saniyede root kabuğu elde etmesini sağlıyor. Üstelik konteyner içinden host makineye kaçış için de kullanılabiliyor. Linux sunucu işletiyorsanız — paylaşımlı hosting, VPS ya da fiziksel sunucu fark etmeksizin — bu haftanın öncelikli yaması bu.

Ne tür bir açık bu?

Açık, kernel/locking/rtmutex.c dosyasında, futex öncelik kalıtımı (PI) yolunda gizleniyor. FUTEX_CMP_REQUEUE_PI çağrısı sırasında çekirdek bir kilitlenme döngüsü tespit edip -EDEADLK ile geri sarma yaparken remove_waiter() yardımcısını çağırıyor. Sorun şurada: bu yardımcı pi_blocked_on alanını temizlemesi gereken uyuyan iş parçacığı yerine o anda çalışan iş parçacığında temizliyor. Sonuçta serbest bırakılmış çekirdek yığın belleğine sallanan bir işaretçi kalıyor — yani yığın use-after-free.

Saldırgan, üç futex ve koordineli iş parçacıklarıyla belirli bir kilitlenme deseni kuruyor, serbest bırakılan çerçeveyi sahte bir bekleyici yapısıyla geri kazanıyor ve oradan isteğe bağlı çekirdek okuma/yazma erişimine, ardından root’a ulaşıyor. Bu açığı Nebula Security ekibi kendi otomatik analiz aracı VEGA ile buldu; istismar kodu yaklaşık beş saniyede %97 oranında başarılı root kabuğu veriyor. CVSS 7.8 (Yüksek). Özel bir ayrıcalık ya da ön erişim gerekmiyor.

Açık Linux 2.6.39’da eklendi; bu da 2011 yılına tekabül ediyor. On beş yıl boyunca neredeyse tüm büyük dağıtımlarda sessizce var oldu, çünkü tek ön koşul olan CONFIG_FUTEX_PI seçeneği varsayılan olarak her yerde etkin geliyor. Geleneksel fuzz testlerinin kolayca kaçırdığı, fakat hedefe yönelik statik analiz araçlarının hızla yakaladığı türden bir yarış durumu. Red Hat konuya ilişkin RHSB-2026-010 güvenlik bültenini yayımladı.

Paylaşımlı hosting ve konteynerler neden daha fazla risk altında

Paylaşımlı hostingde tablo nettir: shell erişimi olan herhangi bir müşteri bu istismarı çalıştırıp root olabilir. Zamanlanmış görev çalıştıran, SSH kullanan ya da etkileşimli terminal gerektiren uygulamaları olan müşteriler de dahil. FUTEX_CMP_REQUEUE_PI sistem çağrısını kısıtlamak glibc’nin POSIX iş parçacığı anlambilimini bozacağından, syscall filtreleme gerçekçi bir geçici çözüm değil. Ya yama yapılır ya da açık kalınır.

Konteyner ortamlarında tablo benzer derecede endişe verici. İstismar, namespace sınırını aşarak çalışıyor; Docker ya da LXC içinden host makineye kaçış mümkün. Konteyner yalıtımı çekirdek düzeyinde sağlanır; çekirdekte böyle bir yetki yükseltme açığı varsa namespace ve cgroup sınırları koruma sağlamaz.

Dağıtımlardaki yama durumu

Ana hat düzeltmesi Linux 7.1’de (commit 3bfdc63936dd) yayımlandı. Geri port yamalar 7–9 Temmuz’dan itibaren dağıtımlara ulaştı. En kapsamlı kamuya açık anlatım AlmaLinux blogunda yer alıyor; yamalar standart üretim depolarında mevcut:

  • AlmaLinux 8: kernel-4.18.0-553.141.2.el8_10 veya üstü
  • AlmaLinux 9: kernel-5.14.0-687.24.1.el9_8 veya üstü
  • AlmaLinux 10: kernel-6.12.0-211.32.1.el10_2 veya üstü
  • CloudLinux: Yamalar yayımlandı — CloudLinux bloguna bakın
  • RHEL / Rocky / Oracle Linux: kpatch güncellemeleri ve tam çekirdek güncellemeleri RHSB-2026-010 kapsamında yayılıyor
  • Debian / Ubuntu: Normal güvenlik kanallarından güncellemeler mevcut

Şimdi ne yapılmalı

Çekirdek güncellemesini kurun ve sunucuyu yeniden başlatın. Çalışma zamanı geçici çözümü bulunmuyor.

# AlmaLinux / RHEL tabanlı
sudo dnf clean metadata && sudo dnf upgrade && sudo reboot

# Debian/Ubuntu
sudo apt update && sudo apt upgrade && sudo reboot

Yeniden başlatmanın ardından uname -r komutuyla yamalı sürümü çalıştırdığınızı doğrulayın. TuxCare KernelCare gibi canlı yama araçları yeniden başlatma gerektirmeden bu yamayı uygulayabilir; yine de yamanın devrede olduğunu teyit edin.

kalfaoglu.net müşterileri için ne anlama geliyor

Yönettiğimiz sunucular 9 Temmuz’dan itibaren, standart bakım penceremiz kapsamında çekirdek güncellemelerini aldı ve yeniden başlatma döngüsü tamamlandı. Altyapımızda bu açık üzerinden hiçbir müşteri verisine erişilmedi.

VPS çekirdeğinizi kendiniz yönetiyorsanız — yani yönetilen güncelleme hizmetimizin dışında kaldıysanız — uname -r komutunu çalıştırıp yukarıdaki yamalı sürümlerle karşılaştırın. Gerideyseniz bir destek talebi açın; güncellemeyi ve yeniden başlatmayı size uygun bir pencerede birlikte planlayalım.

Daha geniş bir değerlendirme olarak: GhostLock, konteyner güvenlik sınırlarının çekirdek tarafından uygulandığını bir kez daha ortaya koyuyor. Çekirdek düzeyinde istismar edilebilir bir LPE açığı olduğunda bu sınırlar anlamsız hale geliyor. Paylaşımlı altyapı üzerinde konteynerlerle hassas iş yükleri çalıştırıyorsanız, AppArmor profilleri, seccomp filtreleri ya da adanmış sanal makinelerin kullanım durumunuza katkı sağlayıp sağlamayacağını değerlendirmek için iyi bir an.