Linux çekirdeğinde yeni açık: ARM64 KVM guest’leri host belleğini okuyup yazabiliyor

Linux çekirdeğinin ARM64 işlemciler için KVM sanallaştırma kodunda yeni bir açık bulundu. Nested virtualization açık olan host’larda, serbest bırakılmış bir host bellek parçası guest sanal makinesine açık kalabiliyor.

CVE-2026-89775 koduyla takip edilen açık, guest’in host çekirdek belleğini okuyup yazmasına izin veriyor. Açığı bulan araştırmacıya göre bu, guest’ten kaçıp host makinede kod çalıştırmak için kullanılabilir.

Etkilenen kod ARM64 için mainline Linux çekirdeğinin parçası. Düzeltme Linux 6.18.51, 7.2.5 ve 7.3-rc1 sürümlerinde yer alıyor.

Önce kapsam: kimleri etkiliyor?

Bu açığı değerlendirirken ilk soru şu olmalı: host’unuzda nested virtualization açık mı? Nested virtualization, bir guest’in kendi hypervisor’ını çalıştırıp kendi sanal makinelerini barındırmasına izin veriyor.

ARM64’te bu özellik varsayılan olarak kapalı. Açılması için boot aşamasında ayarlanan deneysel bir mod gerekiyor ve bu mod FEAT_NV2 özelliğine sahip Armv8.4 donanımı istiyor. Yani nested virtualization’ı hiç açmamış sıradan bir ARM64 KVM host’u, bildirilen saldırı yolunun dışında kalıyor.

Kapsamı daraltan bu koşul önemli, ama kendi ortamınızı kontrol etmeden varsaymamak gerekiyor. ARM64 KVM host’larınızda nested virtualization durumunu şu şekilde kontrol edebilirsiniz:

# çekirdek boot parametrelerinde nested virtualization var mı?
cat /proc/cmdline | grep -o "kvm-arm.mode=[^ ]*"

# çekirdek sürümü
uname -r

kvm-arm.mode=nested görüyorsanız bu açık sizi doğrudan ilgilendiriyor.

Açık teknik olarak nasıl çalışıyor?

Hata, KVM’in ARM64’te nested virtualization’ı yöneten kısmında. Guest belleğini belirli bir şekilde düzenlediğinde bir boyut hesaplaması sıfır çıkıyor. Bunun sonucunda, işlemcinin adres önbelleğindeki eski girdileri temizlemesi gereken adım, yani TLB invalidation, atlanıyor.

Böylece serbest bırakılmış bir host bellek sayfası eşlenmiş ve yazılabilir kalıyor. Guest bu sayfayı 64 bit’lik parçalar halinde okuyup yazabiliyor. Kontrolü host’a geri verecek bir donanım trap’i de yok; yani host bu erişimden haberdar olmuyor.

Klasik bir use-after-free senaryosu: sayfa host tarafında başka bir amaçla yeniden kullanıldığında, guest o sayfadaki host verisini okuyabiliyor ve değiştirebiliyor.

Hangi sürümler etkileniyor?

Burada bir tutarsızlık var. Çekirdeğin kendi kaydı, etkilenen kodun Linux 6.16‘dan beri var olduğunu gösteriyor. Ancak düzeltmenin yazarı onu daha sonraki bir değişikliğe bağladı. Düzeltmeyi inceleyip test eden maintainer’a göre “atlanan invalidation ancak v6.17’de başlıyor”.

Bu değerlendirmeye göre 6.16 çalıştıran bir host kodu taşıyor ama saldırganın ihtiyaç duyduğu davranışı taşımıyor. Pratikte 6.17 ve sonrası asıl risk altında.

İkinci yol: yerel kullanıcıdan root’a

Açığın ikinci bir kötüye kullanım yolu da var. /dev/kvm cihazının, yani bir programın sanal makine oluşturmak için kullandığı cihazın, herkese açık olduğu sistemlerde yerel bir kullanıcı kendi guest’ini kurup aynı hatayla root yetkisi alabiliyor.

Araştırmacı özellikle Red Hat Enterprise Linux‘a dikkat çekiyor: RHEL’de bu cihaz varsayılan olarak tüm kullanıcılara açık. Red Hat, RHEL 10 çekirdeğini etkilenen, 6 ile 9 arası sürümleri etkilenmeyen olarak listeliyor. Bu yol da yine host’ta nested virtualization açık olmasını gerektiriyor.

/dev/kvm izinlerini kontrol etmek için:

ls -l /dev/kvm
# crw-rw-rw- görüyorsanız tüm kullanıcılar erişebiliyor

Bu ikinci yol, çok kullanıcılı ARM64 sunucularda veya paylaşılan CI/CD altyapısında açığın etkisini ciddi şekilde genişletiyor. Guest çalıştırmaya yetkili olmayan sıradan bir kullanıcı bile root olabiliyor.

Dağıtımlara göre durum

Upstream’de açık kapatıldı, ama dağıtımlar düzeltmeyi kendi takvimlerine göre yayınlıyor ve durum sürüme göre değişiyor:

Ubuntu 24.04 LTS kullananlar için ince bir nokta: genel çekirdek güvende, ama donanım uyumluluğu için HWE çekirdeğine geçtiyseniz etkileniyorsunuz. Hangisini kullandığınızı uname -r ile kontrol edin.

Geçici çözüm var mı?

Henüz yamalanamayan host’lar için Red Hat, kendi ölçütlerine göre workaround sayılabilecek bir önlem olmadığını söylüyor. Kesin olan tek şey kapsam: saldırı yalnızca nested virtualization açık host’ları hedefliyor ve bu ARM64’te varsayılan değil.

Buradan çıkan pratik sonuç şu: nested virtualization’ı gerçekten kullanmıyorsanız ama açık bıraktıysanız, onu kapatmak saldırı yolunu ortadan kaldırıyor. Bu resmi bir workaround değil, ama kullanılmayan bir özelliği kapatmak zaten iyi bir pratik.

Puanlama ve istismar durumu

Satıcılar açığı 10 üzerinden 7.8 ile 9.3 arasında puanlıyor. Hepsi etkinin yüksek ve saldırının yerel olduğunda hemfikir; yani açık ağ üzerinden tetiklenemiyor. Puan farkı, her satıcının açığın ne kadar zor istismar edileceğine dair değerlendirmesinden kaynaklanıyor. 9.3 puanını gösteren Ubuntu, kendi önceliğini ise medium olarak belirlemiş.

Araştırmacı açığı 16 Eylül’de oss-security listesinde duyurdu. Yayınlanmış bir exploit kodu yok ve açığın bir saldırıda kullanıldığına dair bir işaret yok. 22 Eylül itibarıyla açık CISA’nın KEV kataloğunda değil ve tahmini istismar skoru %1’in altında.

Bulut kiracıları sağlayıcıya sızabilir mi?

Açık, doğal olarak şu soruyu gündeme getiriyor: bulut kiracıları bu açıkla sağlayıcının makinelerine sızabilir mi? En büyük sağlayıcılarda gereken yapılandırma sunulmuyor:

• Amazon Web Services, nested virtualization için yalnızca Intel tabanlı instance’ları listeliyor
• Google Cloud, ARM sanal makinelerini nested virtualization’dan hariç tutuyor

Bu, o platformlar için kesin bir temiz rapor değil. Ama bu açığın izlediği özel yol, standart ARM tekliflerinde açık değil. Kendi ARM64 KVM altyapısını işleten kurumlar ve küçük bulut sağlayıcıları ise durumlarını ayrıca kontrol etmeli.

Bir yılda dördüncü KVM kaçışı

CVE-2026-89775, güvenlik araştırmacısı Hyunwoo Kim‘in bu yıl açıkladığı dördüncü KVM guest-to-host kaçışı:

Yeni açık en çok, Kim’in Haziran’da yayınladığı ve kamuya gösterilen ilk ARM64 KVM kaçışı olarak tanımladığı ITScape’e benziyor. Tek bir araştırmacının dört ayda dört hypervisor kaçışı bulması, KVM’in nested virtualization gibi karmaşık ve daha az test edilmiş yollarında hâlâ ciddi bir saldırı yüzeyi olduğunu gösteriyor.

Son haftalarda farklı katmanlarda aynı sınıftan açıklar peş peşe geldi: masaüstü sanallaştırmada VMware Workstation ve Fusion’daki VM escape, AI agent izolasyonunda Docker Sandboxes’taki kaçış ve şimdi çekirdek seviyesinde KVM. Ortak nokta aynı: guest ile host arasında köprü kuran kod, izolasyonun en zayıf halkası.

Bu açığın iyi haberi kapsamının dar olması. Nested virtualization ARM64’te varsayılan kapalı ve büyük bulut sağlayıcıları bu yapılandırmayı ARM’da sunmuyor. Kötü haberi ise workaround olmaması ve RHEL 10 gibi /dev/kvm‘i herkese açan sistemlerde yerel kullanıcıdan root’a giden ikinci bir yol bulunması.

Yapılacaklar kısa. ARM64 KVM host’larınızda nested virtualization açık mı kontrol edin. Açıksa ve kullanmıyorsanız kapatın. Kullanıyorsanız dağıtımınızın düzeltmesini takip edin; mainline’da 6.18.51 ve 7.2.5 hazır. Çok kullanıcılı sistemlerde /dev/kvm izinlerini de gözden geçirin.

Kaynak: https://thehackernews.com/2026/09/new-linux-kernel-flaw-gives-arm64-kvm.html