Zapscape erklärt und wie man KVM-Hosts schützt

Die Kurzfassung

Zur Langfassung springen ↓

Worum es geht: CVE-2026-64561, von seinem Entdecker Hyunwoo Kim (@v4bel) „Zapscape“ genannt, ist ein „Use-after-free“-Schwachstelle in der Linux-KVM-x86-Shadow-Memory-Management-Einheit. Zwei Seitenfehlerpfade validieren die Shadow-Root vor der Rückgewinnung von Shadow-Seiten statt danach, sodass KVM weiterhin Zuordnungen unterhalb einer Root erstellt, die durch die Rückgewinnung bereits ungültig gemacht wurde. Das Ergebnis ist ein vollständiger Escape vom Gast zum Host. Der veröffentlichte PoC dokumentiert einen Pfad zur Ausführung von Code als Root auf dem Host, nicht nur einen Panic, der alle gemeinsam genutzten VMs beendet. Zu diesem Abschnitt springen →

Mögliche Auswirkungen: Der Forscher beschreibt einen Weg, über den ein Angreifer von einem von ihm kontrollierten Gast-System aus Code im Host-Kernel ausführen kann, was einem vollständigen Ausbruch aus einer virtuellen Maschine auf den Host entsprechen würde. In derselben Veröffentlichung werden zwei weitere Folgen beschrieben: ein Host-Panic, der alle auf dem betroffenen Rechner laufenden Workloads unterbricht, sowie ein separater Pfad zur lokalen Privilegienerweiterung, der von einem gewöhnlichen Konto auf dem Host ausgeht, wo /dev/kvm ist weltweit beschreibbar. Zu diesem Abschnitt springen →

Schweregrad: Red Hat stuft die Schwachstelle unter CWE-825 als „wichtig“ ein, mit einem CVSS 3.1-Basiswert von 7,0. Die Ausnutzung erfordert Gast-Kernel-Rechte, verschachtelte Virtualisierung und eine kompatible Host-Konfiguration. In der Formulierung von Red Hat werden die Auswirkungen als Instabilität und Denial-of-Service in virtualisierten Umgebungen beschrieben, was deutlich milder klingt als die Darstellung des Forschers. Zu diesem Abschnitt springen →

Wer ist gefährdet: Hosts, auf denen KVM mit aktivierter verschachtelter Virtualisierung auf einem Kernel läuft, der die durch den Commit eingeführte Änderung enthält f95eec9bed76 in Linux 5.9 und enthält noch keine Korrektur aus dem Upstream 2abd5287f083. AMD-SVM-Systeme, die verschachtelte Seitentabellen verwenden, sind am direktesten erreichbar. Bei Intel-Systemen müssen sowohl vier- als auch fünfstufige EPT-Seitenabläufe für den Gast der ersten Ebene verfügbar sein, wodurch dieser Weg auf Ice Lake-SP und neuere Versionen beschränkt ist. Zu diesem Abschnitt springen →

Was wurde überprüft: Der öffentliche Proof-of-Concept hat in unseren Tests bei auf CloudLinux basierenden Kerneln keinen Escape vom Gast zum Host hervorgerufen. Er lässt sich ohne Modifikationen nicht auf diesen Kerneln ausführen, und bei der internen Reproduktion kam es bislang lediglich zu einem Absturz des Gastes der ersten Ebene. Betrachten Sie den Escape als glaubwürdig, jedoch nicht als nachgewiesene Kompromittierung der gesamten Flotte. Zu diesem Abschnitt springen →

Was ist nun zu tun? Finden Sie zunächst heraus, ob ein Host überhaupt in den Untersuchungsbereich fällt.

cat /sys/module/kvm_amd/parameters/nested 2>/dev/null
cat /sys/module/kvm_intel/parameters/nested 2>/dev/null

A 1 oder Y bedeutet, dass das geladene KVM-Modul verschachtelte Virtualisierung zulässt, wodurch der Host in die potenzielle Angriffsfläche gerät. Dies allein beweist noch nicht die Ausnutzbarkeit, da der Status der Kernel-Patches, die Fähigkeiten der Host-CPU, das für L1 zugängliche virtuelle CPU-Modell sowie die Frage, ob ein nicht vertrauenswürdiger Gast L2 erstellen kann, weiterhin eine Rolle spielen.

Keine Ausgabe bedeutet in der Regel, dass das entsprechende KVM-Modul derzeit nicht geladen ist, was nicht dasselbe ist wie „außerhalb des Geltungsbereichs“. Überprüfen Sie daher, wie der Host tatsächlich genutzt wird und ob KVM später geladen werden kann. Lesen Sie die Datei, anstatt anzunehmen, dass niemand die Verschachtelung aktiviert hat, denn im Upstream-KVM ist der Parameter „nested“ seit Linux 4.20 sowohl für Intel als auch für AMD standardmäßig aktiviert, und eine Distribution kann diese Standardeinstellung in beide Richtungen überschreiben.

Deaktivieren Sie die verschachtelte Virtualisierung auf Hosts, die diese nicht benötigen, da dadurch die Voraussetzung entfernt wird, von der die gesamte Kette abhängt. Überprüfen Sie /dev/kvm Berechtigungen als separate Sicherheitsmaßnahme, wenn Sie schon dabei sind.

KernelCare behebt diese Sicherheitslücke im laufenden Kernel ohne Neustart und ohne Neustart der VM. Die ersten Patches, die ohne Neustart auskommen, sind nun verfügbar: Debian 13 befindet sich im Main-Repository, und für Ubuntu 24.04, Ubuntu 24.04 für AWS, Ubuntu 22.04 für AWS (Kernel 6.8) sowie Proxmox VE 8 liegen Builds im Test-Repository vor, die voraussichtlich in das Main-Repository übernommen werden. Die übrigen Kernel-Familien befinden sich noch in der Build- und Prüfphase; die Verfügbarkeit erfolgt je nach Kernel und Repository, sobald die Validierung abgeschlossen ist. Wenden Sie einen korrigierten Hersteller-Kernel an, sofern bereits einer für Ihre Plattform verfügbar ist.

Es kursieren zwei Beschreibungen von „Zapscape“, die sich stark voneinander unterscheiden. Der Forscher beschreibt eine Kette, die dazu führt, dass aus dem Gast heraus Code des Host-Kernels ausgeführt wird. Red Hat beschreibt Instabilitäten in virtualisierten Umgebungen. Beide beziehen sich auf denselben Commit.

Die ehrliche Antwort liegt irgendwo dazwischen, und die nachstehende Erläuterung verdeutlicht, warum. Der intern reproduzierte Fall ist enger gefasst, als die Veröffentlichung vermuten lässt. Der öffentlich vorgestellte Proof-of-Concept kann den vom Angreifer kontrollierten L1-Gast in manchen Umgebungen zum Absturz bringen, während der Forscher einen konfigurationsabhängigen Weg zur Ausführung von Host-Code dokumentiert. Diese Diskrepanz sollte klar herausgestellt werden, und keine der beiden Interpretationen ist ein Argument dafür, eine undichte Virtualisierungsgrenze ungepatcht zu lassen.

Bei der verschachtelten Virtualisierung kann eine virtuelle Maschine eigene virtuelle Maschinen ausführen. Ein Cloud-Kunde könnte diese Funktion nutzen, um einen Hypervisor auszuführen, Infrastruktursoftware zu testen, eine CI-Umgebung zu betreiben oder Windows-Funktionen zu aktivieren, die auf Hyper-V basieren.

Dadurch ergibt sich eine dreistufige Anordnung:

• L0 ist der physische Host
• L1 ist der vom Angreifer kontrollierte Gast
• L2 ist eine virtuelle Maschine, die innerhalb von L1 erstellt wurde

Zapscape nutzt die Speicherverwaltung aus, die L0 bei der Bearbeitung von Aktivitäten aus L2 durchführt. Der Angreifer startet mit Root-Rechten innerhalb von L1 und erstellt den verschachtelten Gast, der erforderlich ist, um den anfälligen KVM-Pfad zu steuern.

Root-Zugriff innerhalb einer virtuellen Cloud-Maschine ist nichts Ungewöhnliches. In der Regel verwalten Kunden ihre Gastbetriebssysteme selbst, und die Schutzgrenze soll verhindern, dass dieser Zugriff den Hypervisor erreicht. Zapscape zielt direkt auf diese Schutzgrenze ab.

KVM verwendet Shadow-Seitentabellen, um Speicherzugriffe des Gastbetriebssystems in Host-Zuordnungen umzuwandeln, und gibt diese Strukturen wieder frei, sobald die Quote für aktive MMU-Seiten erreicht ist.

Die anfälligen Fehlerpfade, direct_page_fault() und FNAME(page_fault)(), genannt is_page_fault_stale() vorher make_mmu_pages_available().

Genau diese Reihenfolge ist der Fehler.

Sanierung im Innenbereich make_mmu_pages_available() kann die von KVM derzeit verwendete Root-Seite löschen und als ungültig markieren. Da die Überprüfung auf veraltete Root-Seiten bereits durchgeführt wurde, fährt KVM fort, Zuordnungen unterhalb einer Root-Seite aufzubauen, die nicht mehr gültig ist. Untergeordnete Schattenseiten erben die Rolle ihrer übergeordneten Seite, sodass sie den ungültigen Status übernehmen, und ungültige Seiten landen schließlich wieder auf der Liste der aktiven MMU-Seiten.

Das ist der invariante Commit f95eec9bed76 wurde in Linux 5.9 hinzugefügt, um dies zu verhindern. Sobald es zu einem Fehler kommt, erfolgt eine spätere rekursive Bereinigung durch mmu_page_zap_pte() läuft ohne root_count überwacht und arbeitet an Strukturen, die bereits freigegeben wurden.

Der Proof-of-Concept steuert den Ablauf, indem er die Speichermodi innerhalb von L1 umschaltet, um Shadow-Seiten zu aliasieren, während die Speicheraktivität aus L2 L0 in eine quotenbasierte Rückgewinnung treibt. Der Forscher nutzt die daraus resultierende Beschädigung anschließend aus, um Code im Host-Kernel auszuführen.

Das Reihenfolgeproblem selbst reicht bis ins Jahr 2008 zurück. In Linux 5.9 wurde es sicherheitsrelevant, als die Invariante eingeführt wurde, gegen die es verstößt. Niemand hat in 5.9 einen Fehler gemeldet. Der Kernel begann einfach, sich auf etwas zu stützen, das nie zutreffend gewesen war.

Der Forscher liefert einen Proof-of-Concept auf Gastseite und dokumentiert einen vollständigen Pfad zur Ausführung von Host-Code. Die Ausnutzbarkeit hängt jedoch stark von der Konfiguration ab. Der Exploit zielt auf AMD ab und wurde für eine bestimmte Linux 7.1.3-Konfiguration unter QEMU TCG entwickelt – nicht auf Produktionshardware. Um einen echten Host zu erreichen, müssten daher die Aktionen auf Gastseite neu geschrieben und an die Konfiguration des Zielkerns angepasst werden.

Bei unseren Tests konnte der vollständige Escape auf keinem mit CloudLinux erstellten Kernel reproduziert werden. Der öffentlich zugängliche Exploit lässt sich ohne Anpassungen nicht auf diesen Kerneln ausführen, und das beobachtete Ergebnis ist ein Absturz des L1-Gasts, was eher einen Denial-of-Service für die eigene virtuelle Maschine des Angreifers darstellt als eine Kompromittierung des Hosts.

Enterprise Linux 8 verdient eine Anmerkung für alle, die dies selbst testen. Der öffentlich zugängliche Proof-of-Concept löst dort keinerlei Probleme aus – nicht einmal einen Absturz –, sodass er nicht als „Vorher-Nachher“-Maßstab für diese Produktfamilie dienen kann. Überprüfen Sie EL8-Kernel anhand einer allgemeinen KVM-Testsuite, anstatt aus dem Ausbleiben von Fehlern Schlussfolgerungen zu ziehen.

Nichts davon beweist, dass die betroffenen Kernel sicher sind. Es bedeutet lediglich, dass die Sicherheitslücke genau beschrieben werden sollte. Zapscape zeigt einen glaubwürdigen Escape-Pfad vom Gast zum Host auf, und der öffentlich zugängliche Exploit stellt derzeit keinen universellen Escape-Pfad für jeden Kernel dar, der den anfälligen Code enthält.

Der anfällige Codepfad besteht seit der Änderung in Linux 5.9 im Commit f95eec9bed76, vom 8. Juli 2020, über Kernel, für die noch kein Fix bereitgestellt wurde 2abd5287f083, das am 21. Juli 2026 stromaufwärts landete.

Die Erreichbarkeit setzt außerdem Folgendes voraus:

• KVM soll im Einsatz sein
• Verschachtelte Virtualisierung soll aktiviert werden
• Steuerung auf Kernel-Ebene innerhalb des L1-Gasts
• Mit dem Angriff kompatible Funktionen der Host-CPU und der virtuellen CPU

Auf AMD-Hosts, die SVM und verschachtelte Seitentabellen verwenden, werden in der Offenlegung keine zusätzlichen CPU-Funktionsvoraussetzungen genannt, die über die bereits aufgeführten Hauptanforderungen hinausgehen. Intel-Systeme sind nur dann betroffen, wenn sowohl vier- als auch fünfstufige EPT-Page-Walk-Längen für L1 verfügbar sind, was im Allgemeinen bedeutet, dass Ice Lake-SP und neuere Systeme mit diesen durchgegebenen Funktionen betroffen sind.

Im Rahmen unserer Analyse identifizierte betroffene oder potenziell betroffene Plattformfamilien:

• Enterprise Linux 10, AlmaLinux 10 und CloudLinux 10, bei denen sich der Backport von CentOS Stream 10 noch im Entwurfsstadium befindet
• Ältere Enterprise Linux 8- und 9-Kernel, die den Hersteller-Fix nicht enthalten, einschließlich von EL8 abgeleiteter Varianten
• Debian 11, 12 und 13
• Ubuntu 22.04 und 24.04
• Oracle UEK7
• Proxmox VE 7 und VE 8

Bereits korrigiert oder nicht im Umfang enthalten:

• RHEL-8-Kernel von 4.18.0-553.147.1.el8_10 weiterhin, versandt am 23. Juli 2026
• RHEL 9-Kernel von 5.14.0-687.30.1.el9_8 weiterhin, Versand am 22. Juli 2026
• RHEL 6 und RHEL 7, einschließlich kernel-rt, die vor der Änderung in Linux 5.9 erschienen sind, durch die die Schwachstelle sicherheitsrelevant wurde
• Jeder Host, auf dem KVM nicht ausgeführt wird oder auf dem KVM mit deaktivierter verschachtelter Virtualisierung ausgeführt wird

Die RHEL-Einträge haben jedoch einen Haken. Red Hat hat die Korrektur stillschweigend im Rahmen anderer Maßnahmen zur Behebung von Sicherheitslücken veröffentlicht, und auf der öffentlichen CVE-Seite wurden RHEL 8 und RHEL 9 auch nach Veröffentlichung dieser Errata weiterhin als betroffen aufgeführt. Die Angaben im Changelog sind aussagekräftiger, und es ist bekannt, dass sich der Status auf der Seite innerhalb weniger Stunden ändern kann. Überprüfen Sie daher die aktuellen Daten von Red Hat noch einmal, bevor Sie einem Kunden oder einem Prüfer mitteilen, dass ein System betroffen ist.

Diese Vorsichtsmaßnahme gilt auch ganz allgemein. Hersteller-Kernel werden ständig mit einzelnen Änderungen nachgerüstet, sodass die Versionsnummer des Upstream-Kernels keinen Aufschluss über das Sicherheitsrisiko gibt. Überprüfen Sie den Sicherheitshinweis und den Patch-Status für den konkret verwendeten Kernel.

So minimieren Sie die Auswirkungen von Zapscape

Jede Voraussetzung für diesen Fehler lässt sich beseitigen. Bei allen drei handelt es sich um vorübergehende Maßnahmen, nicht um Ersatz für die eigentliche Behebung.

1. Deaktivieren Sie die verschachtelte Virtualisierung. Dies ist die direkteste Option, da die Kette L1 benötigt, um eine eigene virtuelle Maschine zu erstellen und zu betreiben.

# /etc/modprobe.d/99-zapscape.conf
options kvm_amd nested=0
options kvm_intel nested=0

Der Modulparameter wird beim Laden ausgelesen; seine Anwendung bedeutet daher, dass alle laufenden virtuellen Maschinen angehalten und neu geladen werden müssen. kvm_amd oder kvm_intel. Auf einem Produktionsserver bedeutet das eine Ausfallzeit oder einen Neustart und keine Änderung im laufenden Betrieb.

Wenn die Infrastruktur gewöhnliche einstufige virtuelle Maschinen betreibt, wenden Sie die Änderung an und fahren Sie fort, da in dieser Workload keine verschachtelte Virtualisierung erforderlich ist. Wenn der Host diese Funktion bewusst bereitstellt – beispielsweise für verschachtelte Hypervisor-Mandanten, CI-Systeme, die virtuelle Maschinen starten, virtualisierte Entwicklungs- und Testumgebungen oder Windows-Gäste, die VBS oder Hyper-V nutzen –, lassen Sie sie aktiviert und konzentrieren Sie sich stattdessen auf die Installation von Patches. Bewerten Sie die Auswirkungen auf die Workloads, bevor Sie Änderungen an einem Host vornehmen, den Sie nicht selbst eingerichtet haben.

2. Zugriff einschränken auf /dev/kvm. Dies bietet keinen Schutz vor einem Angriff durch einen bereits angemeldeten Gast. Es sperrt lediglich den separaten Pfad, über den ein gewöhnlicher lokaler Benutzer auf dem Host direkt auf KVM zugreifen kann.

ls -l /dev/kvm

Wenn das Gerät den Modus anzeigt 0666, ziehen Sie es fest und gewähren Sie berechtigten Benutzern Zugriff über die kvm Gruppe. Nimm diese Änderung in einer udev-Regel vor und nicht mit einem einfachen chmod, da udev den Modus beim nächsten Systemstart oder bei einem Geräteereignis zurücksetzt.

3. Überprüfen Sie die EPT-Exposition auf fünf Ebenen bei Intel. Dies ist nur relevant, wenn beide EPT-Funktionen L1 erreichen.

grep -w ept_5level /proc/cpuinfo

Keine Ausgabe bedeutet, dass dem Host die für den beschriebenen Intel-Pfad erforderliche 5-Level-EPT-Fähigkeit fehlt. Ist das Flag vorhanden, stellt sich als Nächstes die Frage, ob sowohl 4-Level- als auch 5-Level-EPT tatsächlich den nicht vertrauenswürdigen L1-Gast erreichen, da /proc/cpuinfo beschreibt die Host-CPU und nicht das, was das virtuelle CPU-Modell weitergibt. Wenn die verschachtelte Virtualisierung aktiviert bleiben muss, sollten Sie CPU-Modelle vermeiden, die nicht vertrauenswürdigen Gästen EPT auf fünf Ebenen offenlegen. Auf neueren Intel-Systemen ist das Deaktivieren der verschachtelten Virtualisierung nach wie vor die zuverlässigere vorübergehende Kontrollmaßnahme.

Sobald der Schutz eingerichtet ist, entfernen Sie die temporäre Konfiguration mit sudo rm /etc/modprobe.d/99-zapscape.conf und laden Sie das Modul während des nächsten Wartungsfensters neu.

Die Lösung

Die Korrektur im Upstream wurde übernommen. 2abd5287f083, „KVM: x86: Überprüfung auf ungültigen/veralteten Root nach Bereitstellung der MMU-Seiten.“

Die Änderung ist geringfügig. Sie verschiebt die Überprüfung auf veraltete Root-Dateien auf nach make_mmu_pages_available() in beiden betroffenen Fehlerpfaden, bei weniger als einem Dutzend geänderten Zeilen über arch/x86/kvm/mmu/mmu.c und arch/x86/kvm/mmu/paging_tmpl.h. KVM führt nun zunächst eine Freigabe durch und überprüft anschließend, ob die Root noch gültig ist, bevor es fortfährt. Dadurch wird verhindert, dass der Hypervisor aktive Zuordnungen unterhalb einer Root erstellt, die durch die Freigabe bereits ungültig gemacht wurde.

Keine neue Datenstruktur, kein persistenter Zustand, der nachverfolgt werden muss. Das macht es für Patches ohne Neustart geeignet, wobei der Backport selbst davon abhängt, wie stark sich die Fehlerpfade der Kernel der einzelnen Anbieter von der Mainline entfernt haben.

Status und Bereitstellung von KernelCare-Patches

Seit dem 11. August 2026 sind die ersten Veröffentlichungen erhältlich:

Debian 13: Haupt-Repository
Ubuntu 24.04 Noble, Ubuntu 24.04 Noble für AWS, Ubuntu 22.04 Jammy für AWS, 6.8-Kernel und Proxmox VE 8 befinden sich im Test-Repository

Es wurde erwartet, dass die Test-Feed-Builds noch am selben Tag in den Haupt-Feed übernommen werden. Überprüfen Sie daher den Feed-Status für Ihren Kernel, anstatt davon auszugehen, dass es sich noch um reine Testversionen handelt.

Verbleibender Familienstand:

Für jeden Enterprise Linux 9-Kernel liegen Patches in der Überprüfung vor, mit Ausnahme der ältesten Kernel der 70er-Serie, die angepasst werden müssen und auf separate Arbeitsschritte verschoben wurden.

• Die Patches für Ubuntu 24.04 sind fertig und werden derzeit geprüft
• Die Patches für Debian 12 befinden sich derzeit in der Überprüfung und warten auf die Hardware-Validierung.
• Für Enterprise Linux 8 und Ubuntu 22.04 wurden Patches vorbereitet, deren Validierung noch aussteht
• Enterprise Linux 10 steht auf der Warteliste

Bei mehreren Produktfamilien war die AMD-Testhardware und nicht die Komplexität der Patches der begrenzende Faktor. Die Verfügbarkeit wird je nach Kernel variieren, bis die Tests abgeschlossen sind und die Einführung abgeschlossen ist.

Wenn Sie das Update unbedingt durchführen möchten, während sich ein Patch noch im Test-Feed befindet:

kcarectl --update --prefix test

Nach der Bereitstellung im Produktions-Feed wird der Patch beim nächsten planmäßigen Durchlauf oder auf Abruf bereitgestellt:

kcarectl --update

Überprüfen Sie anschließend, was tatsächlich auf dem laufenden Kernel geladen ist:

kcarectl --patch-info | grep 'CVE-2026-64561'

Ein Erstellungszeitstempel dient als sekundäre Überprüfung:

kcarectl --info | grep kpatch-build-time

Ein Build vom 6. August 2026 oder später ist ein nützlicher Anhaltspunkt, jedoch keine Garantie dafür, dass diese spezifische CVE in diesem Kernel abgedeckt ist. Falls die CVE in den Patch-Informationen noch nicht aufgeführt ist, sollten Sie die Abdeckung für den jeweiligen Kernel über den Kundensupport bestätigen lassen, anstatt das Datum als Nachweis heranzuziehen. In jedem Fall sollten Sie dies vor dem Entfernen einer vorübergehenden Abhilfemaßnahme überprüfen – nicht erst danach.

Erfahren Sie, wie KernelCare kritische Kernel-Sicherheitslücken ohne Neustart behebt →

Zeitleiste

Referenzen

• Hyunwoo Kim (@v4bel), Offenlegung von Zapscape gegenüber oss-security
• Technischer Bericht und Proof-of-Concept zu Zapscape, zapscape.io
• Upstream-Linux-Korrektur 2abd5287f083, „KVM: x86: Auf ungültigen/veralteten Root prüfen, nachdem MMU-Seiten bereitgestellt wurden“
• Linux-Commit f95eec9bed76, „KVM: x86/mmu: Ungültige SPs nicht wieder in die Liste der aktiven Seiten aufnehmen“
• Red Hat-Sicherheitshinweis und CVE-Eintrag für CVE-2026-64561
• CentOS Stream 10: Backport-Merge-Request 3068, im Entwurfsstadium
• Betroffene Sicherheitshinweise für RHEL, AlmaLinux, CloudLinux, Debian, Ubuntu, Oracle und Proxmox