Januscape: Use-after-free in KVM/shadow MMU bedroht Linux-Hosts

Im Hypervisor KVM des Linux-Kernels wurde eine use-after-free-Schwachstelle (CVE-2026-53359) entdeckt, die es einer Gast-VM ermöglicht, den Zustand der Shadow-Seiten des Host-Kernels zu beschädigen. Der verwundbare Code war seit 2010 im Kernel vorhanden – rund 16 Jahre. Ein öffentlicher PoC-Exploit mit dem Namen Januscape demonstriert einen zuverlässig reproduzierbaren Absturz des Hosts, was zu einem Denial of Service für alle virtuellen Maschinen auf dem physischen Server führt. Das Problem betrifft x86-Hosts mit Intel- und AMD-Prozessoren bei aktivierter Nested Virtualization. Ein Patch ist verfügbar – Administratoren von Multi-Tenant-KVM-Umgebungen sollten ihn mit hoher Priorität einspielen.

Technische Details der Schwachstelle

Der Fehler befindet sich im Code der shadow MMU – dem Mechanismus der Shadow-Page-Tables, den KVM verwendet, um den Speicher der Gastmaschinen nachzuverfolgen. Wenn eine vorhandene Shadow-Seite erneut genutzt werden sollte, hat KVM sie nur anhand der Speicherframe-Adresse (GFN) zugeordnet, jedoch nicht den Typ (die Rolle) dieser Seite geprüft. Zwei unterschiedliche Typen von Shadow-Seiten können dieselbe Adresse haben, aber völlig verschiedene Funktionen erfüllen. Das führte dazu, dass KVM eine Seite des falschen Typs wiederverwenden konnte und so die innere Konsistenz seiner Datenstrukturen verletzte.

In den meisten Fällen erkennt der Kernel die Beschädigung und beendet die Ausführung mit einem Panic – genau das demonstriert der öffentliche PoC Januscape: Ein ladbares Kernelmodul in der Gast-VM löst innerhalb von Sekunden oder Minuten einen Panic auf dem Host aus, abhängig vom Timing der Race Condition. Es gibt jedoch ein gefährlicheres Szenario: Wenn eine freigegebene Shadow-Seite vor ihrer Bereinigung bereits für andere Zwecke erneut allokiert wird, schreibt die Bereinigungsroutine einen Wert in Speicher, der ihr nicht mehr gehört. Nach Angaben des Forschers kontrolliert der Angreifer, wohin geschrieben wird, auch wenn er den geschriebenen Wert nicht kontrolliert – doch selbst dieser eingeschränkte Primitive kann für eine weitergehende Eskalation ausreichen.

Der verwundbare Code wurde im August 2010 mit dem Commit 2032a93d66fa eingeführt (zur Ära von Kernel 2.6.36). Der Fix – Commit 81ccda30b4e8 – wurde am 19. Juni 2026 in den Mainline-Branch übernommen. Autor des Patches ist der KVM-Maintainer Paolo Bonzini. Die Korrektur besteht in einer einzeiligen Ergänzung der Funktion kvm_mmu_get_child_sp(): Die Bedingung für die Wiederverwendung prüft nun role.word zusätzlich zur GFN.

Ausnutzungsbedingungen und Umfang der Bedrohung

Für eine Ausnutzung müssen seitens der Gastmaschine zwei Bedingungen erfüllt sein:

• Root-Rechte innerhalb der VM – eine verbreitete Voraussetzung bei gemieteten Cloud-Instanzen.
• Verschachtelte Virtualisierung (nested virtualization), die auf dem Host aktiviert ist. Selbst wenn der Host standardmäßig Hardware-EPT (Intel) bzw. NPT (AMD) verwendet, zwingt verschachtelte Virtualisierung KVM dazu, den veralteten Pfad über die shadow MMU zu nutzen, in dem sich der Fehler befindet.

Der Exploit benötigt keine Interaktion mit QEMU oder einem anderen User-Space-VMM – es handelt sich um einen rein kernelinternen Fehler in KVM. Das praktische Risiko konzentriert sich auf x86-Umgebungen, die nicht vertrauenswürdige Mandanten mit Zugriff auf Nested Virtualization bedienen. Ein Angreifer, der eine solche Instanz gemietet hat, kann den Host zum Absturz bringen und alle benachbarten virtuellen Maschinen auf demselben physischen Server außer Betrieb setzen.

Nach Angaben des Forschers kann dieselbe Schwachstelle auf Distributionen wie RHEL, bei denen /dev/kvm die Zugriffsrechte 0666 hat (für alle Nutzer zugänglich), potenziell auch für eine lokale Privilegieneskalation bis root ausgenutzt werden, obwohl der primäre Angriffsvektor der Ausbruch aus der Gastmaschine bleibt.

Es ist bemerkenswert, dass CVE-2026-53359 bereits die zweite use-after-free-Schwachstelle in der shadow MMU innerhalb von zwei Monaten ist. Im Mai 2026 wurde ein ähnliches, aber separates Problem CVE-2026-46113 behoben, das mit einem rmap-Mismatch im selben Legacy-Code zusammenhing. Das weist auf eine strukturelle Fragilität des veralteten shadow-MMU-Pfads hin.

Kontext: eine Serie von Enthüllungen eines Forschers

Januscape ist die dritte publik gemachte Kernel-Schwachstelle von Hyunwoo Kim (@v4bel) innerhalb von rund zwei Monaten. Im Mai 2026 veröffentlichte er Dirty Frag (CVE-2026-43284 / CVE-2026-43500) – eine Kette von Schwachstellen bei Schreibzugriffen auf den Page Cache. Im Juni folgte ITScape (CVE-2026-46316) – der erste öffentlich demonstrierte Ausbruch aus einer Gastmaschine auf KVM/arm64 über eine Race Condition im virtuellen Interrupt-Controller. Januscape komplettiert das Bild auf der x86-Seite.

Laut Kim wurde der Exploit als Zero-Day-Fund in das Programm Google kvmCTF eingereicht, das 2024 gestartet wurde und Belohnungen von bis zu 250.000 US-Dollar für einen vollständigen Ausbruch aus einer Gast-VM bietet. Diese Aussage ist jedoch von Google in offenen Quellen nicht bestätigt.

Praktische Empfehlungen

Stabile Kernel-Versionen mit Fix wurden am 4. Juli 2026 veröffentlicht:

• 7.1.3, 6.18.38, 6.12.95, 6.6.144, 6.1.177, 5.15.211, 5.10.260

Vorrangige Maßnahmen:

1. Prüfen Sie die Verfügbarkeit des Patches. Stellen Sie sicher, dass der Kernel den Commit 81ccda30b4e8 enthält. Distributionsseitige Backports können den Fix unter einer anderen Versionsnummer enthalten – prüfen Sie das Changelog des Pakets und verlassen Sie sich nicht nur auf die Ausgabe von uname -r.
2. Wenn ein sofortiges Update nicht möglich ist, deaktivieren Sie Nested Virtualization für nicht vertrauenswürdige Gäste per Modulparameter: kvm_intel.nested=0 oder kvm_amd.nested=0. Dies beseitigt den Angriffsvektor vollständig.
3. Bewerten Sie die Konfiguration des Zugriffs auf /dev/kvm. Auf Systemen, auf denen dieses Device-File für alle Nutzer zugänglich ist, sollten Sie eine Einschränkung der Zugriffsrechte in Betracht ziehen.

Die NVD hat für CVE-2026-53359 bislang noch keinen CVSS-Score vergeben. ARM64-Hosts sind von dieser Schwachstelle nicht betroffen – ITScape (CVE-2026-46316) stellt ein separates Problem für KVM/arm64 dar.

Der öffentliche PoC demonstriert einen zuverlässig reproduzierbaren Absturz des Hosts, und zwei shadow-MMU-Schwachstellen innerhalb von zwei Monaten deuten auf aufgelaufene technische Schulden im Legacy-KVM-Code hin. Administratoren von x86-KVM-Hosts mit Nested Virtualization und Multi-Tenant-Zugriff sollten das Kernel-Update auf eine korrigierte Version als Aufgabe mit hoher Priorität betrachten und nicht auf eine CVSS-Bewertung warten.