Intel- und AMD-x86-Systeme betroffen 16 Jahre alte Linux-KVM-Schwachstelle ermöglicht Ausbruch aus Gast-VMs

Von Melanie Staudacher 3 min Lesedauer

Ein 16 Jahre alter Fehler im KVM-Hypervisor von Linux ermöglicht es Angreifern, aus einer virtuellen Maschine auszubrechen und die Kontrolle über den Host zu übernehmen. Betroffen sind sowohl Intel- als auch AMD-x86-Systeme.

Der Sicherheitsforscher Hyunwoo Kim hat eine 16 Jahre alte KVM-Schwachstelle entdeckt, die auf Intel- und AMD-x86-Systemen einen Ausbruch aus Gast-VMs auf den Host ermöglicht.(Bild:  Dall-E / Vogel IT-Medien GmbH / KI-generiert)
Der Sicherheitsforscher Hyunwoo Kim hat eine 16 Jahre alte KVM-Schwachstelle entdeckt, die auf Intel- und AMD-x86-Systemen einen Ausbruch aus Gast-VMs auf den Host ermöglicht.
(Bild: Dall-E / Vogel IT-Medien GmbH / KI-generiert)

Der Sicherheitsforscher Hyunwoo Kim hat eine Sicherheitslücke in der Kernel-based Virtual Machine (KVM) von Linux entdeckt, die es Angreifern ermöglicht, aus einer virtuellen Gastmaschine (Guest-VM) auszubrechen und die Kontrolle über das zugrunde liegende physische Hostsystem zu übernehmen. Hintergrund der Schwachstelle EUVD-2026-41666 / CVE-2026-53359 (CVSS-Score nicht vergeben, EPSS-Score* 0.18) ist ein „Use-after-Free“-Fehler im Linux-KVM-Hypervisor. Dieser kann von einer virtuellen Gastmaschine aus ausgelöst werden, um den „Shadow-Page“-Zustand des Host-Kernels zu beschädigen – also jene internen Verwaltungsdaten, mit denen KVM die Zuordnung zwischen virtuellem Gast-Speicher und physischem Host-Speicher nachhält –, auf dem die VM läuft.

Kim nannte die Schwachstelle „Januscape“. Sie befindet sich im Shadow-MMU-Code, Teil des Linux-Kernels, der die Shadow-Pagin-Funktionalität implementiert. Die KVM verwendet diesen Code sowohl für Intel- als auch für AMD-Systeme. Kim bezeichnete Januscape als den ersten Exploit für einen Ausbruch vom Gast zum Host, der sowohl auf Intel- als auch auf AMD-Systemen ausgelöst werden kann. Besonders brisant: Die Schwachstelle blieb rund 16 Jahre lang unentdeckt. Kim habe einen Teil des Exploits bei Googles dediziertem Bug-Bounty-Programm für KVM-Hypervisor, „kvmCTF“, eingereicht.

Wie funktioniert der VM-Ausbruch?

Wie der Ausbruch aus der virtuellen Maschine technisch funktioniert, wird bei The Hacker News gut erklärt: KVM verwalte zur Ausführung einer virtuellen Maschine einen eigenen Satz privater Seitentabellen (Page Tables), die das Speicherlayout des Gastes widerspiegeln. Werde eine dieser Überwachungsseiten (Tracking Pages) benötigt, suche KVM nach einer bereits vorhandenen Seite, die wiederverwendet werden könne. Das Problem dabei sei, dass die Zuordnung ausschließlich anhand der Speicheradresse erfolge, ohne zu berücksichtigen, um welchen Typ von Überwachungsseite es sich handele. Da zwei verschiedene Typen dieselbe Adresse nutzen könnten, aber völlig unterschiedliche Aufgaben erfüllten, verwende KVM bisweilen den falschen Typ. Diese Verwechslung bringe die internen Aufzeichnungen von KVM darüber, welche Seite wohin gehöre, durcheinander. Und sobald diese Informationen fehlerhaft seien, komme es zwangsläufig zu Problemen.

Meist bemerke der Kernel dieses Chaos und fahre das System sofort herunter, um Schäden zu vermeiden. Genau diesen Absturz löse Kims Exploit aus: Ein Gastsystem könne den gesamten Host zum Absturz bringen und dabei alle anderen auf diesem Rechner laufenden VMs mitreißen. Der seltenere, aber gefährlichere Fall trete ein, wenn die freigegebene Überwachungsseite für einen anderen Zweck neu vergeben werde, bevor der Kernel die Bereinigung abgeschlossen habe. Bei der anschließenden Bereinigung werde dann ein Wert in einen Speicherbereich geschrieben, über den das System nicht mehr verfüge. Ein Angreifer könne dann kontrollieren, an welcher Stelle der Schreibvorgang erfolge, jedoch nicht, was geschrieben werde. Doch selbst dieser begrenzte Ansatzpunkt lasse sich nutzen, um ausführbaren Code auf dem Host-System zu implementieren.

Die Schwachstelle verhalte sich auf Intel- und AMD-Chips identisch, wofür in beiden Fällen Root-Rechte innerhalb der Gast-VM erforderlich seien. Nur der letzte Schritt, die Erlangung der vollständigen Kontrolle, erfordere bei den jeweiligen Architekturen unterschiedliche Vorgehensweisen.

Patch und Workaround

Betroffen von der Sicherheitslücke sind alle x86-Umgebungen, in denen nicht vertrauenswürdige Gastsysteme mit aktivierter Nested Virtualization gehostet werden. Ein Angreifer, der eine solche Instanz mietet, kann alle anderen Gast-VMs auf derselben physischen Maschine zum Absturz bringen.

Der fehlerhafte Code existiert seit dem Commit 2032a93d66fa aus dem Jahr 2010. Erst 16 Jahre später wurde er nun mit dem Commit 81ccda30b4e8 behoben, der in den Mainline-Kernel integriert wurde. Die korrigierten Stable-Versionen sind 7.1.3, 6.18.38, 6.12.95, 6.6.144, 6.1.177, 5.15.211 und 5.10.260.

Wer nicht sofort patchen kann, sollte die Nested Virtualization deaktivieren. Dies geht über die Einstellung „kvm_intel.nested=0“ beziehungsweise „kvm_amd.nested=0“

* Hinweis zum EPSS-Score: Das Exploit Prediction Scoring System zeigt die Wahrscheinlichkeit in Prozent an, mit der eine Schwachstelle innerhalb der nächsten 30 Tage ausgenutzt wird. Der ent­sprechende Score kann sich im Laufe der Zeit verändern. Sofern nicht anders angegeben, beziehen wir uns auf den Stand des EPSS-Scores zum Zeitpunkt der Veröffentlichung des Artikels.

(ID:50894337)

Jetzt Newsletter abonnieren

Täglich die wichtigsten Infos zur IT-Sicherheit

Mit Klick auf „Newsletter abonnieren“ erkläre ich mich mit der Verarbeitung und Nutzung meiner Daten gemäß Einwilligungserklärung (bitte aufklappen für Details) einverstanden und akzeptiere die Nutzungsbedingungen. Weitere Informationen finde ich in unserer Datenschutzerklärung. Die Einwilligungserklärung bezieht sich u. a. auf die Zusendung von redaktionellen Newslettern per E-Mail und auf den Datenabgleich zu Marketingzwecken mit ausgewählten Werbepartnern (z. B. LinkedIn, Google, Meta).

Aufklappen für Details zu Ihrer Einwilligung