Linux-KVM-ARM64-Schwachstelle ermöglicht Gästen Zugriff auf Host-Speicher

Eine neu bekannt gewordene Schwachstelle im KVM-Virtualisierungscode des Linux-Kernels für ARM64-Prozessoren kann dazu führen, dass eine freigegebene Seite des Host-Speichers von einer virtuellen Maschine auf derselben physischen Maschine lesbar und beschreibbar bleibt, so der Forscher, der sie entdeckt hat. Der Fehler wird als CVE-2026-89775 geführt und ist in Linux 6.18.51, 7.2.5 und 7.3-rc1 behoben. KVM, was für Kernel-based Virtual Machine steht, ist der in Linux integrierte Teil, der es einem physischen Computer ermöglicht, mehrere separate virtuelle Computer gleichzeitig auszuführen. Der Host ist die darunterliegende echte Maschine; ein Gast ist eine der darauf laufenden virtuellen Maschinen. Die Schwachstelle betrifft nicht jedes Linux-System, und die Anbieter, die sie bewerten, stufen die Auswirkungen als hoch ein, stimmen aber darin überein, dass es schwierig ist, sie zu erreichen, da sie nur dort relevant ist, wo eine selten genutzte Funktion namens verschachtelte Virtualisierung absichtlich aktiviert wurde.

Der Fehler liegt in dem Abschnitt von KVM, der die verschachtelte Virtualisierung auf ARM64 behandelt, dem 64-Bit-Prozessordesign, das in vielen Servern und Cloud-Rechenzentren verwendet wird. Verschachtelte Virtualisierung bedeutet, dass ein Gast seinen eigenen Hypervisor ausführen darf, die Softwareebene, die normalerweise virtuelle Maschinen erstellt und verwaltet, sodass ein Gast eigene virtuelle Maschinen hosten kann. Wenn ein Gast seinen Speicher auf eine bestimmte Weise anordnet, ergibt eine Größenberechnung im Kernel null. Das führt dazu, dass ein Schritt übersprungen wird, der veraltete Einträge aus dem Translation Lookaside Buffer des Prozessors löschen sollte; dieser Puffer ist ein kleiner, schneller Cache, der festhält, wo sich Speicherstücke aktuell befinden. Weil die Löschung, bekannt als TLB-Invalidierung, nie stattfindet, bleibt eine Seite des Host-Speichers, die der Kernel bereits freigegeben hat, für den Gast gemappt und beschreibbar. Der Gast kann dann diesen Speicher 64 Bit gleichzeitig lesen und schreiben, und kein Hardware-Trap gibt die Kontrolle an den Host zurück, während er dies tut.

Hyunwoo Kim, der Sicherheitsforscher, der die Schwachstelle gemeldet hat, veröffentlichte sie am 16. September und sagt, dass ein Gast sie nutzen kann, um aus seiner eigenen virtuellen Maschine auszubrechen und Code auf der zugrunde liegenden physischen Maschine auszuführen, ein Ergebnis, das als Guest-to-Host-Escape bekannt ist. Das ist der Worst Case und nicht der Alltag: Es wurde kein Exploit-Code veröffentlicht, und es gibt keine Anzeichen dafür, dass die Schwachstelle in einem Angriff genutzt wurde.

Die Einschränkungen, wer betroffen ist, sind genauso wichtig wie der Fehler selbst. Verschachtelte Virtualisierung ist auf ARM64 standardmäßig deaktiviert. Es ist ein experimenteller Boot-Time-Modus, der Armv8.4-Hardware mit einer Prozessorfunktion namens FEAT_NV2 benötigt, und ein einfacher ARM64-KVM-Host, der ihn nie aktiviert, liegt außerhalb des gemeldeten Angriffspfads. Die gefährdeten Maschinen sind also diejenigen, deren Betreiber die Fähigkeit absichtlich aktiviert haben, normalerweise weil sie virtuelle Maschinen innerhalb virtueller Maschinen für Tests, Entwicklung oder einen spezialisierten Dienst ausführen möchten.

Es gibt auch einige Uneinigkeit darüber, wie weit das Problem zurückreicht. Der Kernel-eigene Datensatz listet den betroffenen Code als ab Linux 6.16 vorhanden, aber der Autor des Fixes hat ihn gegen eine spätere Änderung getaggt, und der Maintainer, der den Patch überprüft und getestet hat, sagte, dass die verpasste Invalidierung erst ab v6.17 beginnt. Demnach trägt ein Host auf 6.16 den Code, aber nicht das Verhalten, das ein Angreifer benötigt.

Kim beschreibt einen zweiten Weg, dieselbe Schwachstelle auszunutzen. Auf Systemen, auf denen jedem Benutzer erlaubt ist, /dev/kvm zu öffnen, die Gerätedatei, die ein Programm verwendet, um eine virtuelle Maschine zu erstellen, könnte ein lokaler Benutzer, der bereits ein Konto auf der Maschine hat, einen Gast erstellen und den Fehler nutzen, um Root zu erlangen, das Administratorkonto, das volle Kontrolle über ein Linux-System hat. Er verweist auf Red Hat Enterprise Linux, wo dieses Gerät standardmäßig für alle Benutzer offen ist. Red Hat listet seinen Kernel der Version 10 als betroffen und die Versionen 6 bis 9 als nicht betroffen. Dieser Weg erfordert immer noch, dass der Host verschachtelte Virtualisierung aktiviert hat.

Fixes kommen nach dem jeweiligen Zeitplan der Anbieter. Upstream ist die Schwachstelle in Linux 6.18.51, 7.2.5 und 7.3-rc1 behoben. Auf Ubuntu ist Version 26.04 anfällig, einschließlich ihrer Amazon Web Services-, Microsoft Azure- und Google Cloud-Kernel, während der allgemeine 24.04 LTS-Kernel nicht betroffen ist; Ubuntus neuere Hardware-Enablement-Kernel 6.17 und 7.0 sind anfällig. Auf Amazon Linux wartet das AL2023-Kernel6.18-Paket noch auf einen Fix, und andere Amazon-Linux-Kernel sind nicht betroffen. Debians Bookworm- und Trixie-Releases sind nicht betroffen, weil der Code nicht vorhanden ist, Sid ist in 7.2.6-1 behoben, und Forky ist anfällig. Für Hosts, die noch nicht gepatcht werden können, sagt Red Hat, dass keine Maßnahme seine Kriterien für einen Workaround erfüllt.

Die Anbieter bewerten die Schwachstelle zwischen 7,8 und 9,3 von 10. Sie stimmen darin überein, dass die Auswirkungen hoch sind und dass der Angriff lokal ist, was bedeutet, dass er nicht über ein Netzwerk gestartet werden kann und ein Angreifer bereits einen Fuß in der Maschine haben müsste. Die Spanne spiegelt wider, wie schwierig jeder Anbieter die Ausnutzung einschätzt, und Ubuntu, das die Zahl 9,3 veröffentlicht, setzt seine eigene Priorität auf mittel. Stand 22. September war die Schwachstelle nicht im U.S.-CISA-Katalog der ausgenutzten Schwachstellen, und ihr vorhergesagter Ausnutzungswert lag unter 1 %.

Die Offenlegung wirft die offensichtliche Frage auf, ob ein Cloud-Mieter den Fehler nutzen könnte, um in die eigenen Maschinen eines Anbieters einzubrechen. Bei den größten Anbietern ist die benötigte Konfiguration nicht im Angebot: Amazon Web Services listet nur Intel-basierte Instanzen für verschachtelte Virtualisierung, und Google Cloud schließt seine ARM-virtuellen Maschinen davon aus. Das ist kein sauberes Gesundheitszeugnis für diese Plattformen, aber der spezifische Weg, den diese Schwachstelle nimmt, ist in ihren Standard-ARM-Angeboten nicht exponiert.

CVE-2026-89775 ist der vierte KVM-Guest-to-Host-Escape, den Kim dieses Jahr offengelegt hat. Zwei waren in der x86-Version von KVM: Januscape im Juli und Zapscape im August. Der, dem er am meisten ähnelt, ist ITScape, ein ARM64-KVM-Escape, den er im Juni veröffentlichte und als den ersten öffentlich gezeigten solchen Escape auf ARM64 beschrieb.

Für Website-Besitzer und IT-Teams ist die praktische Frage, ob die Maschinen, auf die sie sich verlassen, in die oben beschriebene enge Gruppe fallen. Die meisten kleinen Websites liegen auf Shared- oder Managed-Hosting, wo verschachtelte Virtualisierung keine Rolle spielt, aber wer einen ARM-basierten Linux-Server, eine private Cloud oder ein Testlabor betreibt, sollte die Kernel-Version mit der obigen Liste abgleichen und bestätigen, ob verschachtelte Virtualisierung überhaupt aktiviert ist. Wo mehrere Personen eine Maschine teilen, ist es wissenswert, ob normale Konten /dev/kvm öffnen können, da dies die Konfiguration hinter dem zweiten Angriffspfad ist. Für Organisationen, die einen strukturierten Blick darauf werfen möchten, wie ihre Server und virtuellen Maschinen konfiguriert sind, beschreibt AEU-I, der sicherheitsorientierte IT-, Infrastruktur- und Beratungsservice der AEU Group, auf seiner eigenen Seite, was er abdeckt.