CVE-2026-89775: ARM64-KVM-Gast kann Host-Kernelspeicher lesen und schreiben
Im ARM64-KVM-Code des Linux-Kernels bleibt bei aktivierter Nested Virtualization eine freigegebene Host-Speicherseite für den Gast sichtbar und beschreibbar. Behoben in Linux 6.18.51, 7.2.5 und 7.3-rc1. Nested Virtualization ist auf ARM64 standardmäßig aus, x86-Hosts sind vom gemeldeten Pfad nicht betroffen.
Im KVM-Code des Linux-Kernels für ARM64-Prozessoren steckt eine Schwachstelle, die einem Gastsystem Lese- und Schreibzugriff auf bereits freigegebenen Host-Kernelspeicher erlauben kann. Betroffen sind ausschließlich ARM64-Hosts, auf denen die verschachtelte Virtualisierung (Nested Virtualization) aktiv eingeschaltet wurde. Diese Betriebsart ist auf ARM64 standardmäßig ausgeschaltet, gilt als experimentell, muss beim Booten aktiviert werden und setzt Armv8.4-Hardware mit dem Merkmal FEAT_NV2 voraus. Wer einen gewöhnlichen ARM64-KVM-Host betreibt und diesen Modus nie eingeschaltet hat, liegt außerhalb des gemeldeten Angriffspfads. x86-Hosts sind vom gemeldeten Pfad nicht betroffen.
Handlungsbedarf am selben Tag besteht damit nur für eine kleine Gruppe: ARM64-Hosts mit eingeschalteter Nested Virtualization, auf denen fremde oder nicht vollständig vertrauenswürdige Gastsysteme laufen. Alle anderen können den Fix im regulären Wartungsfenster einspielen. Es gibt keinen veröffentlichten Exploit-Code und keinen Hinweis auf eine Ausnutzung in freier Wildbahn. Zum Hintergrund früherer KVM-Ausbruchslücken hatten wir bereits über ZapScape und CVE-2026-64561 berichtet, dabei handelt es sich aber um eine andere Schwachstelle mit anderem Mechanismus.
Was ist passiert?
Der Sicherheitsforscher Hyunwoo Kim hat die Schwachstelle am 16. September 2026 offengelegt. Sie wird als CVE-2026-89775 geführt und sitzt in dem Teil von KVM, der die verschachtelte Virtualisierung auf ARM64 behandelt. Verschachtelte Virtualisierung bedeutet, dass ein Gastsystem selbst wieder einen Hypervisor betreiben und eigene virtuelle Maschinen hosten darf.
Der Fehler lässt sich technisch gut eingrenzen. Ordnet der Gast seinen Speicher auf eine bestimmte Weise an, ergibt eine Größenberechnung im Kernel den Wert null. In der Folge wird ein Schritt übersprungen, der veraltete Einträge aus dem Adresscache des Prozessors entfernen soll, eine sogenannte TLB-Invalidierung. Eine bereits freigegebene Speicherseite des Hosts bleibt dadurch beim Gast eingeblendet und beschreibbar.
Praktisch heißt das: Der Gast kann diesen Host-Kernelspeicher lesen und schreiben, jeweils 64 Bit am Stück, ohne dass eine Hardwarefalle die Kontrolle an den Host zurückgibt. Der Entdecker gibt an, ein Gast könne das nutzen, um aus der eigenen virtuellen Maschine auszubrechen und Code auf der darunterliegenden Maschine auszuführen. Diese Aussage stammt vom Entdecker und ist bislang nicht durch einen veröffentlichten Exploit belegt.
Wer ist betroffen?
Der betroffene Code gehört zum Mainline-Linux-Kernel für ARM64. Upstream behoben ist das Problem in Linux 6.18.51, 7.2.5 und 7.3-rc1.
- ARM64-Hosts mit KVM, auf denen Nested Virtualization beim Booten aktiviert wurde und deren Hardware Armv8.4 mit FEAT_NV2 unterstützt. Das ist der gemeldete Angriffspfad.
- Nicht betroffen nach heutigem Stand: ARM64-KVM-Hosts ohne eingeschaltete Nested Virtualization, also die Standardkonfiguration.
- Nicht betroffen nach heutigem Stand: x86-Hosts. Der gemeldete Pfad bezieht sich ausdrücklich auf den ARM64-spezifischen Codeteil.
- Red Hat stuft den Kernel von RHEL 10 als betroffen ein. RHEL 6 bis 9 sind laut Red Hat nicht betroffen.
- Andere Distributionen liefern den Fix nach eigenen Zeitplänen aus. Der Status unterscheidet sich je Release und muss beim jeweiligen Anbieter geprüft werden.
Bei den betroffenen Versionsständen gibt es eine offene Unsicherheit, die nicht glattgebügelt werden sollte. Der Kernel-Eintrag nennt den betroffenen Code ab Linux 6.16. Der Autor des Fixes hat diesen jedoch gegen eine spätere Änderung getaggt, und der prüfende Maintainer erklärte, die fehlende Invalidierung beginne erst ab Version 6.17. Nach dieser Darstellung trägt ein Host auf 6.16 zwar den Code, aber nicht das für einen Angriff nötige Verhalten. Wer auf 6.16 unterwegs ist, sollte die Lage deshalb beobachten und im Zweifel trotzdem aktualisieren, statt sich auf eine der beiden Lesarten festzulegen.
Wie kritisch ist das?
Technisch ist das Fehlerbild schwerwiegend: Schreibzugriff auf freigegebenen Host-Kernelspeicher aus einem Gast heraus ist die klassische Grundlage für einen Ausbruch aus der virtuellen Maschine. Operativ wird die Lage aber stark durch die Voraussetzungen entschärft. Nested Virtualization ist auf ARM64 kein Standard, sondern ein experimenteller Modus, der bewusst eingeschaltet werden muss und passende Hardware voraussetzt.
Ein zweiter Angriffspfad verdient Aufmerksamkeit in Mehrbenutzerumgebungen. Auf Systemen, auf denen jeder Benutzer das Gerät /dev/kvm öffnen darf, könnte ein lokaler Benutzer eine eigene virtuelle Maschine bauen und über denselben Fehler Root-Rechte erlangen. Kim verweist hier auf Red Hat Enterprise Linux, wo dieses Gerät standardmäßig für alle Benutzer offen ist. Auch dieser Pfad setzt voraus, dass Nested Virtualization auf dem Host aktiviert ist.
Was gesichert ist: der Fehlermechanismus, die Fix-Versionen und die Einstufung durch Red Hat. Was offen ist: der genaue Startpunkt der Betroffenheit zwischen 6.16 und 6.17 sowie die praktische Ausnutzbarkeit, da kein Exploit-Code vorliegt. Eine akute Notfalleskalation ist nach aktuellem Stand nicht angezeigt, eine gezielte Bestandsprüfung dagegen schon.
Was sollten Admins jetzt tun?
- Inventar zuerst: Prüfen, ob überhaupt ARM64-KVM-Hosts im Bestand sind. Auf jedem dieser Hosts die Kernelversion mit
uname -rerfassen und gegen 6.18.51, 7.2.5 beziehungsweise 7.3 abgleichen. - Feststellen, ob Nested Virtualization tatsächlich eingeschaltet ist. Sie ist auf ARM64 standardmäßig aus und muss als Boot-Parameter gesetzt worden sein, also Bootloader-Konfiguration und
/proc/cmdlineprüfen. - Hardwarelage klären: Ohne Armv8.4 und das Merkmal FEAT_NV2 lässt sich der Modus gar nicht nutzen. Das grenzt den Kreis betroffener Maschinen weiter ein.
- Patchstand beim eigenen Distributor prüfen statt nur Upstream. Bei Red Hat Enterprise Linux 10 den Kernel-Patchstand gezielt nachziehen, RHEL 6 bis 9 gelten laut Hersteller als nicht betroffen.
- Wo ein Update kurzfristig nicht möglich ist: Nested Virtualization auf betroffenen Hosts abschalten, sofern sie fachlich nicht zwingend gebraucht wird. Das entfernt den gemeldeten Angriffspfad vollständig.
- Zugriff auf
/dev/kvmprüfen und einschränken. Auf Mehrbenutzersystemen sollte nicht jeder Konto-Inhaber das Gerät öffnen dürfen, sondern nur eine definierte Gruppe. - Gastvertrauen bewerten: Hosts, auf denen fremde oder von Kunden gestellte Gastsysteme laufen, zuerst patchen. Rein intern betriebene Gastsysteme sind nachrangig.
- Nach dem Patch einen Neustart einplanen und die neue Kernelversion verifizieren. Ein eingespieltes Paket ohne Reboot wirkt beim laufenden Kernel nicht.
- Dokumentieren, welche Hosts geprüft und welche als nicht betroffen eingestuft wurden. Das erspart bei der nächsten KVM-Meldung eine komplette Neubewertung.
- Meldungen zu veröffentlichtem Exploit-Code beobachten. Sollte ein Proof of Concept erscheinen, ändert sich die Dringlichkeit für Hosts mit aktiver Nested Virtualization sofort.
Einordnung für Unternehmen
Für die meisten kleinen und mittleren Unternehmen ist die praktische Betroffenheit gering. Virtualisierungshosts laufen dort typischerweise auf x86-Hardware, und selbst auf ARM64-Systemen ist verschachtelte Virtualisierung selten produktiv im Einsatz. Wer Proxmox, libvirt oder KVM auf klassischer Serverhardware betreibt, muss hier nicht kurzfristig reagieren.
Relevanter wird die Meldung in zwei Konstellationen. Erstens bei ARM64-Servern in der Cloud oder im Rechenzentrum, wo verschachtelte Virtualisierung für Test- und Entwicklungsumgebungen bewusst aktiviert wird. Zweitens bei Mehrbenutzer-Linux-Systemen, auf denen Entwickler eigene virtuelle Maschinen starten dürfen und der Zugriff auf /dev/kvm nicht eingeschränkt ist. In beiden Fällen ist der Aufwand für die Prüfung klein und der Gewinn an Sicherheit gemessen daran groß.
Unabhängig von diesem Einzelfall zeigt die Meldung eine wiederkehrende Betriebsregel: Experimentelle Kernelfunktionen gehören nur dort aktiviert, wo sie fachlich gebraucht werden. Jeder eingeschaltete Sondermodus vergrößert die Angriffsfläche, auch wenn er im Alltag unsichtbar bleibt. Eine dokumentierte Übersicht der gesetzten Boot-Parameter ist deshalb kein Selbstzweck, sondern spart bei genau solchen Meldungen Stunden.
Passende Anleitungen auf S-EDV
- ZapScape: CVE-2026-64561 erlaubt KVM-Guest-Escape und lokalen Root Hintergrund zu einer früheren, anders gelagerten KVM-Ausbruchslücke.
- SUSE: spice-vdagent-Lücken im KVM-Gast zeigt, warum auch Komponenten innerhalb des Gastsystems zur Angriffsfläche gehören.
- Proxmox VE installieren und grundkonfigurieren für eine saubere Ausgangsbasis beim Betrieb von KVM-Virtualisierung.
