Linux çekirdeğinde yıllardır gizli kalan bir XFS açığı, yerel ayrıcalıksız kullanıcıların root’a yükselmesine ve hedef dosyaları kalıcı biçimde bozmasına yol açabiliyor. CVE-2026-64600 olarak izlenen hata, reflink açık XFS dosya sistemlerinde belirli koşullar oluştuğunda etkili oluyor; varsayılan Red Hat Enterprise Linux kurulumları ile Fedora Server ve Amazon Linux türevleri de bu koşulları karşılayabiliyor.
Araştırmacılar, açığın /etc/passwd gibi root sahipli dosyalara karşı yarış koşulu oluşturarak istismar edilebildiğini, ayrıca setuid-root ikililer üzerinde de etkili olduğunu gösterdi. Yazma işlemi blok katmanına kadar indiği için değişiklikler yeniden başlatma sonrasında da kalıyor; dosyanın sahipliği, izinleri, zaman damgaları ve setuid biti ise yerinde duruyor.
Kimler risk altında, hangi kurulumlar etkileniyor
Açığın çalışması için üç şart gerekiyor: Sistem Linux 4.11 ya da daha yeni bir çekirdek kullanacak, RefluXFS düzeltmesini içermeyecek ve XFS dosya sistemi reflink=1 ile oluşturulmuş olacak. Bunun üzerine saldırganın yazabildiği bir dizin ile okunabilir hedef dosyanın aynı XFS dosya sisteminde bulunması gerekiyor.
Bu koşullar sağlandığında, yerel kod çalıştırabilen her ortam risk altına giriyor. Qualys, özellikle çok kiracılı sunucuların ve untrusted kodun çalışabildiği sistemlerin önce yamalanması gerektiğini belirtti; buna bir kabuk erişimi, CI işi ya da ele geçirilmiş bir servis üzerinden girilen sistemler de dahil.
Advisory’de yer alan varsayılan kurulumlar arasında Red Hat Enterprise Linux, CentOS Stream, Oracle Linux, Rocky Linux, AlmaLinux ve CloudLinux 8, 9 ve 10; Fedora Server 31 ve sonrası; Amazon Linux 2023; ayrıca Aralık 2022 ve sonrasında yayımlanan Amazon Linux 2 imajları bulunuyor. RHEL 7 dosya sistemleri etkilenmiyor, çünkü bu sürümler XFS reflink desteğinden önceki döneme ait.
Debian, Ubuntu, SLES ve openSUSE dağıtımları ise kök dosya sistemi için varsayılan olarak genellikle XFS kullanmıyor. Bu sistemler ancak yönetici kurulum sırasında XFS’yi reflink açık şekilde seçtiyse risk grubuna giriyor.
Yöneticiler kök dosya sisteminde reflink durumunu xfs_info / | grep reflink= komutuyla kontrol edebiliyor. Çıktıda reflink=1 görülmesi, ikinci koşulun karşılandığı anlamına geliyor. Aynı kontrol, korunan bir dosya ile saldırganın yazabildiği bir dizinin aynı dosya sistemini paylaştığı diğer bağlı XFS hacimleri için de yapılabiliyor.
Yarışın işlendiği nokta blok katmanına kadar uzanıyor
Saldırı zinciri, saldırganın root sahipli bir dosyayı FICLONE ile geçici bir dosyaya kopyalamasıyla başlıyor. Bu işlem kaynak dosyada yalnızca okuma izni gerektiriyor. Ardından saldırgan, kopya üzerinde eşzamanlı O_DIRECT yazmaları ile yarış kuruyor.
XFS reflink yapısı copy-on-write mantığıyla çalıştığı için iki dosya başlangıçta aynı fiziksel disk bloklarını paylaşıyor. Çekirdek, inode kilidi altında veri-fork eşlemesini okuyor ve bunu xfs_reflink_fill_cow_hole() fonksiyonuna iletiyor. Bu noktada kilit, işlem alanı ayırmak için bırakılıp tekrar alınırken kısa bir pencere açılıyor.
Bu aralıkta ikinci bir yazıcı copy-on-write işlemini tamamlayıp klon dosyayı yeni bir bloğa yeniden eşleyebiliyor. İlk yazıcı kilidi yeniden aldığında, copy-on-write fork’u tazeliyor ama eski veri-fork eşlemesini kullanmayı sürdürüyor. Yani kontrol edilen adres artık güncel değil.
Upstream yama bu durumu açık biçimde “ILOCK’u yeniden aldığımız anda eşlemeler stale oluyor” diye tarif ediyor. Eski blok adresi artık yalnızca korunan orijinal dosyanın kullandığı bir noktaya işaret ediyor. XFS o bloğu paylaşımsız gördüğü için doğrudan yazmaya izin veriyor ve saldırganın kopyasına gitmesi gereken veri hedef dosyaya düşüyor.
Bu, kilit bırakılıp yeniden alındıktan sonra yapılan bir kontrolün eski bilgiye dayanması nedeniyle ortaya çıkan bir check-then-use hatası. Paylaşımlı durum sorgusu kendi başına yanlış değil; sorun, sorgunun kilit bırakılmadan önce yakalanmış bir blok adresi üzerinden yapılması.
İncelemede yamanın iki yardımcı işleve dokunduğu görüldü: xfs_reflink_fill_cow_hole() ve xfs_reflink_fill_delalloc(). İkinci yardımcıda da aynı kilit döngüsü modeli bulunuyor, ancak bu parça Qualys duyurusunda yer almıyor. Düzeltme, her iki yerde de ip->i_df.if_seq sayaç değerini kilit düşmeden önce kaydediyor; sayaç değişmişse veri-fork yeniden xfs_bmapi_read() ile okunuyor.
Direct I/O, sayfa önbelleğini atladığı ve yeniden doğrulama kancası kullanmadığı için yazma doğrudan diske ulaşıyor. Hedef inode üzerinden geçmediğinden metadata da değişmiyor. Araştırmacılar, testlerinde çekirdek uyarısı ya da günlük kaydı oluşmadığını söyledi.
Test makinesinde yarış çoğu zaman on saniyenin altında kazanıldı. Yayımlanan gösterimde, varsayılan bir RHEL 10.2 sisteminde root parolasının silinebildiği belirtildi.
Qualys, açığın bir yapay zekâ modeli tarafından bulunduğunu açıkladı. Şirkete göre Claude Mythos Preview adı verilen, Anthropic’in kısıtlı erişimli ileri modeli çekirdeğe karşı yönlendirildi ve modelden Dirty COW benzeri bir açık bulması istendi. Model yarış koşulunu tespit etti, çalışır durumda bir root istismarı yazdı ve duyuru metnini de hazırladı.
Ardından araştırmacılar aynı bulguyu Fedora Server 44 kurulumunda yeniden üretti, modelin mantığını doğruladı ve koordineli bildirimi çekirdek ekosistemiyle paylaştı. Bu yıl içinde keşfedilen yaşlı çekirdek hatalarının listesi de uzuyor; Qualys bir gün önce Ubuntu Desktop’taki snap-confine açığını, yani CVE-2026-8933’ü açıklamıştı. Mayıs ayında ise çekirdeğin ptrace kontrollerindeki dokuz yıllık bir hata kamuya duyurulmuştu.
Red Hat, etkilenen RHEL 8, 9 ve 10 akışları için Important dereceli çekirdek duyuruları yayımladı. Yama takvimi 14 Temmuz’da işlemeye başladı, yani koordineli duyurudan sekiz gün önce. RHEL 8 için RHSA-2026:39179 ve RHSA-2026:39180, RHEL 10 için RHSA-2026:39494 yayımlandı; uzatılmış destek ve SAP akışları da 17 Temmuz’a kadar güncellendi.
Burada kapsam akış bazında değiştiği için, yöneticilerin kendi sürümleri için ayrı bir duyuru olup olmadığını kontrol etmesi gerekiyor. Bu yamanın zamanında uygulanmış olması, RefluXFS adını almadan önce sistemi korumuş sayılıyor.
Red Hat’in hata izleyicisinde açık “kernel: XFS data corruption using reflink” başlığıyla yer alıyor. Kayıt 10 Temmuz’da otomatik olarak içeri aktarılmış ve ilk açıklama, reflinking sırasında olası veri bozulmasına işaret etmişti.
23 Temmuz itibarıyla Debian’ın izleyicisinde düzeltme trixie-security için kernel 6.12.96-1, unstable içinse 7.1.4-1 olarak listeleniyordu. Trixie’nin temel çekirdeği 6.12.94-1, forky’nin 7.1.3-1 sürümleri ise hâlâ savunmasız işaretlenmişti; bookworm ve bullseye ile bunların security kolları da aynı durumdaydı.
Bir dosya sistemi oluşturulduktan sonra XFS reflink’i kapatan bir mount seçeneği ya da sysctl bulunmuyor. Qualys, pratik bir geçici önlem ya da geçici yapılandırma değişikliği olmadığını belirtti. Şirketin testlerinde SELinux Enforcing modu, seccomp, kernel lockdown ve konteyner sınırları da saldırıyı durduramadı. KASLR ve SMEP gibi bellek korumalarıysa devreye girmedi, çünkü burada bellek taşması değil blok katmanına yazılan bir veri var.
Görünürde bir sınır gibi duran bir nokta da tam bir sınır değil. Yarış ancak hedef bloğun başlangıçta paylaşımsız olması halinde çalışıyor; bu nedenle yönetici tarafından daha önce reflink ile kopyalanmış bir dosya hedef alınamıyor. Yine de advisory, ayrıcalıksız bir kullanıcının chsh çalıştırarak bu koşulu sıfırlayabildiğini ve setuid-root ikililerin zaten çoğunlukla reflink ile kopyalanmamış olduğunu belirtiyor.
Qualys, bağımsız istismar kodu yayımlamadı. Red Hat’in hata izleyicisine göre 22 Temmuz’da kamuya açık bir proof-of-concept kaydı eklendi ve bu kayıt, oss-security listesinde paylaşılan duyuruyu işaret ediyor. Bildirimin yapıldığı sırada açığın gerçek dünyada aktif şekilde kullanıldığına dair bir veri bulunmuyordu.
Yama paketi kurmak, bellekte çalışan çekirdeği otomatik olarak değiştirmiyor. Bu nedenle güncellemenin ardından sistemi yeniden başlatmak ve düzeltmeli çekirdekle açıldığını doğrulamak gerekiyor.