ITScape: Der erste KVM/arm64-Guest-to-Host-Escape-Exploit

Der Fehler sitzt direkt in der Funktion vgic_its_invalidate_cache(). Diese durchläuft den ITS-eigenen Übersetzungscache mit xa_for_each() und ruft vgic_put_irq() für den durchlaufenen Zeiger auf, anstatt für den Wert, der sicher von xa_erase() zurückgegeben wird. Da mehrere Kontexte unter verschiedenen Sperren in diese Funktion eintreten können, ist die Race-Condition vollständig vom Gastsystem aus erreichbar, indem man ITS-Befehle mit einem GITS_CTLR-Schreibzugriff und dem Löschen von EnableLPIs in einem Redistributor kombiniert .

Warum das wichtig ist: Der erste KVM/arm64-Guest-to-Host-Escape

Gast-zu-Host-Ausbrüche sind selten, gehören aber zur gefährlichsten Klasse von Hypervisor-Fehlern, da sie die Isolationsgrenze durchbrechen, auf der das gesamte Cloud-Computing basiert. Bisherige öffentliche KVM-Ausbrüche zielten auf x86-Systeme ab, meist über QEMU oder AMD-spezifischen Code . ITScape ist der erste funktionierende Exploit, der einen Ausbruch einer unprivilegierten arm64-VM durch den In-Kernel-KVM-Code selbst demonstriert – ganz ohne Fehler im Userspace-Emulator .

Für Cloud-Anbieter, die AWS-Graviton-Instanzen, Ampere-Altra-Server oder andere arm64-KVM-Hosts mit mandantenfähigen Workloads betreiben, hat dies gravierende Folgen. Ein Gast kann:

• Beliebigen Host-Kernel-Speicher lesen und schreiben
• Sich Codeausführung auf Ring-0-Ebene des Hosts verschaffen
• Lateral auf andere VMs, Container oder das Host-Netzwerk übergreifen

Die meisten Sicherheitsteams bewerten die Schwachstelle mit einem CVSS-Wert von über 9,0, was die höchste Kritikalität widerspiegelt .

Die Ursache im Detail

Der verwundbare Code liegt im Invalidierungspfad des LPI-Übersetzungscaches. Wenn der Kernel Cache-Einträge leeren muss, iteriert er mit xa_for_each() durch das XArray und ruft vgic_put_irq() auf, um den Referenzzähler für jeden Eintrag zu senken. Das Problem: xa_for_each() kann Einträge zurückgeben, die von einer gleichzeitigen Operation – etwa einem DISCARD-ITS-Befehl einer anderen vCPU – bereits gelöscht wurden. Die Invalidierungsschleife senkt den Referenzzähler für diesen bereits entfernten Eintrag dennoch, was zu einer doppelten Freigabe und schließlich zu einem Use-after-Free führt .

Eine frühere Schwachstelle im selben Code, CVE-2024-26598, hatte eine ähnliche UAF-Lücke im Trefferpfad des LPI-Übersetzungscaches teilweise behoben, indem der Referenzzähler innerhalb von vgic_its_check_cache() vor dem Freigeben der Sperre erhöht wurde. Dieser Fix deckte den Invalidierungspfad jedoch nicht ab, sodass die Race-Condition durch eine andere Befehlssequenz weiterhin ausnutzbar blieb .

Der Patch

Der offizielle Upstream-Fix modifiziert vgic_its_invalidate_cache() so, dass vgic_put_irq() nur noch für den von xa_erase() zurückgegebenen Wert aufgerufen wird, nicht für jeden Eintrag, den der Iterator berührt. Die Commit-Nachricht lautet: "KVM: arm64: vgic-its: Drop the translation cache reference only for the erased entry" (dt.: „Gebe die Referenz des Übersetzungscaches nur für den tatsächlich gelöschten Eintrag frei“) .

Da xa_erase() den alten Eintrag atomar entfernt und zurückgibt – oder NULL zurückgibt, falls der Eintrag bereits weg war – stellt der Fix sicher, dass der Referenzzähler genau einmal dekrementiert wird, und eliminiert so das Zeitfenster für die doppelte Freigabe. Der Patch wurde Anfang Juni 2026 in den Upstream-Kernel aufgenommen und kurze Zeit später, um den 8. bis 10. Juni 2026, schnell in die stabilen 6.x-Kernel-Serien übernommen . Große Distributionen wie Red Hat, SUSE und Debian haben Backports für ihre unterstützten Kernel-Zweige veröffentlicht .

Betroffene Versionen

• Eingeführt: Ende April 2024, als der LPI-Übersetzungscache erstmals zu KVM/arm64 hinzugefügt wurde
• Verwundbares Zeitfenster: Upstream-Kernel, die etwa zwischen April 2024 und Anfang Juni 2026 kompiliert wurden
• Behoben: Upstream-Fix von Anfang Juni 2026; enthalten in den neuesten 6.x-Stable-Kerneln und Distributions-Backports

Der Proof-of-Concept-Exploit

Hyunwoo Kim veröffentlichte den funktionierenden Exploit um den 9. bis 10. Juni 2026 öffentlich auf GitHub. Das Repository enthält den vollständigen Quellcode, eine Schritt-für-Schritt-Anleitung zur Reproduktion sowie eine technische Beschreibung der Exploitation-Technik . Der Exploit triggert die Race-Condition, indem er vCPU-Threads koordiniert, die gleichzeitig DISCARD-Befehle ausführen und Lookups im LPI-Übersetzungscache vornehmen, um den Use-After-Free präzise für die Host-Codeausführung auszunutzen.

Die öffentliche Verfügbarkeit eines zuverlässigen PoCs bedeutet, dass standardisierte Exploit-Scanner und echte Angreifer die Schwachstelle mit minimalem Aufwand waffenfähig machen können. Das verkürzt das Zeitfenster zwischen der Offenlegung und aktiven Angriffen erheblich.

Dringende Abhilfemaßnahmen für ARM64-Cloud-Betreiber

Wenn Sie eine mandantenfähige arm64-KVM-Infrastruktur betreiben – mit AWS Graviton, Ampere Altra oder einer ähnlichen Plattform – betrachten Sie diesen Vorfall als sofortigen Notfall-Patch-Zyklus.

1. Patchen Sie den Host-Kernel jetzt. Spielen Sie den neuesten Stable-Kernel ein, der den Fix von Anfang Juni 2026 enthält, oder das Backport-Paket Ihrer Distribution .
2. Deaktivieren Sie das In-Kernel-vGIC-ITS für nicht vertrauenswürdige Gastsysteme, falls ein sofortiges Patchen nicht möglich ist. Mit QEMU kann dies erzwungen werden, indem die GICv3-ITS-Emulation in den Userspace verlagert oder GICv3-ITS-Fähigkeiten gegenüber nicht vertrauten Mietern nicht offengelegt werden .
3. Verlassen Sie sich nicht auf eine Härtung des Gastsystems. Dies ist ein Fehler auf der Hypervisor-Ebene; es gibt keine Abhilfemaßnahme innerhalb der VM .
4. Überprüfen Sie Ihre Server-Flotte auf verwundbare Kernel. Jeder arm64-KVM-Host mit einem Kernel, der zwischen April 2024 und Anfang Juni 2026 kompiliert wurde und den vGIC-ITS nutzt, ist gefährdet .
5. Überwachen Sie auf Anzeichen einer Ausnutzung. Mit dem öffentlich verfügbaren PoC-Code sind aktive Scans und Kompromittierungsversuche hochwahrscheinlich .