Januscape deckt den KVM-Shadow-Paging-Fehler auf, der immer wieder auftrat

Gehen Sie direkt zu einer KI-Zusammenfassung dieses Blogbeitrags

Die Kurzfassung

Was es ist: Januscape (CVE-2026-53359) ist ein „Use-after-free“-Fehlfehler in der KVM/x86-Shadow-MMU des Linux-Kernels. Ein böswilliger Gast kann KVM dazu bringen, eine zwischengespeicherte Shadow-Seite wiederzuverwenden, die nicht mehr mit der gerade erstellten Zuordnung übereinstimmt, wodurch ein veralteter Reverse-Map-Eintrag zurückbleibt, der auf Speicherbereich verweist, den KVM später freigibt. Zur ausführlichen Version springen →

Auswirkung: Das nachweisbare, öffentlich bekannte Ergebnis ist ein Host-Absturz. In öffentlichen Forschungsberichten wird ein vollständiger Escape vom Gast zum Host beschrieben – Code innerhalb eines bösartigen Gastes, der auf dem Host als Root ausgeführt wird. Wir haben die Beschädigung des Host-Speichers und die Denial-of-Service-Primitiv unter AlmaLinux 9 und Ubuntu 24.04 unabhängig bestätigt, konnten jedoch die vollständige Escape-Kette nicht reproduzieren. Auf Systemen der RHEL-Familie, auf denen /dev/kvm für alle zugänglich ist, ermöglicht derselbe Fehler eine lokale Privilegienerweiterung auf Root. Zur Langfassung springen →

Status: Im Upstream behoben (Commit 81ccda30b4e8, im Juni 2026 in den Mainline integriert). Das NVD hat die CVE am 4. Juli 2026 veröffentlicht, und die Sperrfrist endete am 6. Juli. Es handelte sich um eine Zero-Day-Einreichung beim kvmCTF; für Verteidiger ist es heute ein N-Day mit einem öffentlichen Proof-of-Concept. Zur Langfassung springen →

Schweregrad: NVD hatte zum Zeitpunkt der Veröffentlichung noch keinen CVSS-Wert zugewiesen. Das Fehlen eines Werts bedeutet nicht, dass die Auswirkungen gering sind. Bewerten Sie den Schweregrad intern als „hoch“ und warten Sie nicht auf die farbliche Kennzeichnung. Zur Langfassung springen →

Wer ist betroffen: KVM/x86-Hosts (Intel und AMD), die den Gästen verschachtelte Virtualisierung zur Verfügung stellen. Der Escape-Pfad erfordert neben den Root-Rechten des Gastes noch eine weitere Voraussetzung: verschachtelte Virtualisierung. Zur ausführlichen Version springen →

Zugehörige Sicherheitslücke: Januscape erfordert eine zweite Korrektur (CVE-2026-46113), um vollständig geschlossen zu werden. Das Beheben der früheren Sicherheitslücke allein reicht nicht aus, um Januscape zu stoppen. Zur ausführlichen Version springen →

Gehen Sie wie folgt vor: Patchen Sie betroffene KVM-Hosts mit einem korrigierten Kernel oder einem Patch, der keinen Neustart erfordert. Auf Hosts, auf denen keine VMs laufen, können die KVM-Module entladen und gesperrt werden. Auf Hosts, auf denen VMs laufen, die jedoch keine verschachtelte Virtualisierung benötigen, sollte diese deaktiviert werden, wodurch der Escape-Pfad für nicht vertrauenswürdige Gäste entfernt wird. Bei Hosts, die beides benötigen, lässt sich das Problem nicht allein durch die Konfiguration beheben. Zur ausführlichen Version springen →

Möchten Sie KVM-Hosts aktualisieren, ohne jede VM neu starten zu müssen?

KernelCare installiert Sicherheitspatches für den Linux-Kernel ohne Ausfallzeiten, Unterbrechungen der Arbeitsabläufe oder Notfallwartungsfenster.
KernelCare-Status: Seit dem 7. Juli 2026 werden für mehrere Kernel-Familien Patches ohne Neustart bereitgestellt, die sowohl CVE-2026-53359 als auch den erforderlichen Begleitpatch CVE-2026-46113 abdecken; weitere Patches befinden sich in aktiver Entwicklung. Der vollständige Release-Status und die K-Tags sind unten aufgeführt.

KernelCare herunterladen →

Die Langfassung

Januscape stellt das zentrale Versprechen der Virtualisierung infrage.

Eine Gast-VM kann kompromittiert, vom Kunden gesteuert, veraltet, absichtlich bösartig oder einfach nur falsch konfiguriert sein. In keinem dieser Fälle sollte sie Zugriff auf den Speicher des Hosts erhalten. Die Aufgabe von KVM besteht darin, den Gastspeicher sicher zu übersetzen und dabei diese Trennung aufrechtzuerhalten. Januscape untergräbt die Verwaltungsmechanismen hinter dieser Übersetzung.

Der Fehler befindet sich in der Datei „arch/x86/kvm/mmu/mmu.c“ in der KVM-Shadow-MMU. Dieser Code verwaltet die hostseitigen Seitentabellenstrukturen, die die von einem Gast verwendeten Adressen auf den vom Host freigegebenen Speicher abbilden. Bei einer kontrollierten Abfolge von Änderungen an der Gastzuordnung verwendet KVM eine vorhandene Schatten-Seite erneut, obwohl deren gespeicherte Rolle nicht mehr mit der gerade erstellten Zuordnung übereinstimmt. Durch diese Wiederverwendung bleibt ein Reverse-Map-Eintrag zurück, der auf eine Struktur verweist, die KVM später freigibt, und ein anschließender Durchlauf der Reverse-Map führt zu einer Dereferenzierung der freigegebenen Seite.

Eines vorweg, denn dies entscheidet darüber, wer gefährdet ist. Es handelt sich hierbei nicht um einen Datenkonflikt im klassischen Sinne, und es ist auch nicht derselbe Fehler wie bei seinem „Bruder“. Der Kernel stuft Januscape als „Use-after-free“ ein, der durch eine unerwartete Rolle der Shadow-Page verursacht wird. Der Auslöser besteht darin, dass eine Gastzuordnung asynchron von außerhalb des eigenen Page-Walks des Gastes geändert wird, sodass das Auslösen des Fensters zeitlichen Druck erfordert. Die eigentliche Ursache ist jedoch ein fehlender Vergleich und kein Sperrfehler. Behalten Sie diese Unterscheidung im Hinterkopf, denn daraus ergeben sich die Behebung und die Abhilfemaßnahmen.

So funktioniert Januscape

Im Überblick:

[Guest with root + nested virtualization exposed]
│  forces KVM back through the legacy shadow MMU
▼
[Guest creates a large 2 MB mapping → KVM builds a direct shadow page]
│
▼
[Guest rewrites the mapping to a 4 KB page-table path]
│  new mapping needs a non-direct (direct=0) page
▼
[kvm_mmu_get_child_sp() reuses the old direct page – gfn matches, role NOT compared]
│
▼
[Cleanup computes the wrong frame number → reverse-map entry not removed]
│
▼
[Shadow page freed; stale reverse-map entry left behind]
│  later rmap walk (dirty logging / MMU-notifier invalidation)
▼
[Use-after-free write of a fixed marker into freed memory]
▼
[Host crash (public PoC)  →  or guest-to-host escape, root on host (withheld exploit)]

Ein detaillierter Blick auf diesen Ablauf: Die Sequenz beginnt mit einem Eintrag im Seitenverzeichnis des Gastes, der eine große 2-MB-Zuordnung beschreibt. KVM erstellt eine „kvm_mmu_page“, die 512 einzelne 4-KB-Einträge umfasst, und markiert die Schattenseite als „direct“, da es sich bei der Zuordnung des Gastes um eine zusammenhängende große Seite handelt.

Die Zuordnung wird dann außerhalb des normalen Ausführungsablaufs des Gastes geändert. Anstelle einer großen Seite verweist derselbe Seitenverzeichniseintrag nun auf eine andere Seitentabelle, die einzelne 4-KB-Zuordnungen enthält. KVM benötigt für diese Struktur eine andere Art von Schattenseite: Die ursprüngliche hat eine direkte Rolle, die neue Zuordnung benötigt eine nicht-direkte. Der anfällige Pfad „kvm_mmu_get_child_sp()“ vergleicht diese vollständige Rolle nicht, bevor entschieden wird, die vorhandene Seite wiederzuverwenden. Da die Frame-Nummer übereinstimmt, wird die Seite akzeptiert, und KVM legt einen neuen Leaf-Eintrag an und speichert einen Reverse-Map-Eintrag für den Frame, der durch den neuen Durchlauf ermittelt wurde.

Der Fehler tritt während der Bereinigung zutage. Da die wiederverwendete übergeordnete Seite weiterhin angibt, direkt zu sein, berechnet KVM den Frame für den neuen 4-KB-Eintrag als sp->gfn + Index, anstatt die gespeicherte Shadow-Übersetzung zu verwenden. Anschließend sucht es unter der falschen Frame-Nummer nach dem Reverse-Map-Eintrag und kann diesen nicht entfernen. Die Shadow-Seite wird freigegeben, doch der veraltete Reverse-Map-Eintrag bleibt zurück. Jeder spätere Vorgang, der diese Reverse-Map durchläuft, dereferenziert einen Eintrag innerhalb der freigegebenen Seite. Der Kernel nennt „Dirty Logging“ und „MMU-Notifier-Invalidation“ als die Vorgänge, die dies bewirken.

Es gibt ein Detail, das sowohl den öffentlich zugänglichen PoC als auch den zurückgehaltenen Exploit erklärt. Während des Teardowns schreibt KVM eine feste Markierungskonstante in einen Speicherbereich, der nun möglicherweise neu zugewiesen wird. Dabei handelt es sich um einen echten „Use-after-free“-Schreibvorgang, allerdings um einen eingeschränkten: einen festen Wert an einer Adresse, die der Angreifer mit einem brauchbaren Kernel-Objekt in Einklang bringen muss. Es ist schwierig, diese Ausrichtung zuverlässig zu erreichen, weshalb der öffentlich zugängliche Code nur dazu führt, dass der Host abstürzt, und der vollständige Escape noch nicht veröffentlicht wurde.

Der Gast gelangt über verschachtelte Virtualisierung an diesen Code. Auf einem modernen Host, auf dem Gäste mit Hardware-Paging (EPT bei Intel, NPT bei AMD) ausgeführt werden, wird die Software-Shadow-MMU normalerweise nicht genutzt. Erst durch die Aktivierung der verschachtelten Virtualisierung wird KVM gezwungen, wieder auf die ältere Shadow-MMU zurückzugreifen – und genau dort befindet sich Januscape. Das ist der Grund, warum ein Host modern erscheinen kann und dennoch voll und ganz in den Anwendungsbereich fällt.

Was wir bestätigt haben

Unsere Tests haben bestätigt, dass der anfällige Zustand sowohl auf einem Enterprise-Linux-Kernel als auch unter Ubuntu 24.04 erreichbar ist. Wir konnten den Host-DoS-Angriff und die Speicherbeschädigung reproduzieren. Den End-to-End-Escape – bei dem es sich um den vom Forscher zurückgehaltenen Exploit handelt – haben wir nicht ausgeführt.

Unter AlmaLinux 9 mit dem Kernel 5.14.0-687.5.3.el9_8 führte der Trigger zu einem schwerwiegenden Kernel-Fehler in der Funktion `pte_list_remove()`. Der Host stürzte innerhalb von Sekunden bis Minuten ab, während der aktive Prozess `qemu-kvm` war. Dies ist ein reproduzierbarer, vom Gast ausgelöster Denial-of-Service-Angriff auf den Host unter dem getesteten Kernel.

Unter Ubuntu 24.04 mit dem Kernel 6.8.0-111-generic führte dieselbe Beschädigung zu einer Warnung statt zu einem sofortigen Panic. Der Kernel meldete eine GFN-Diskrepanz in `kvm_mmu_page_set_translation()` – wodurch die zugrunde liegende Frame-Verwechslung sichtbar wurde –, gefolgt von einer nachgelagerten Warnung bei `pte_list_remove()`. Der Host blieb funktionsfähig, da diese Konsistenzprüfungen in dieser Ubuntu-Version als Warnungen und nicht als fatale Fehlerprüfungen behandelt werden; daher lief er mit einem beschädigten Shadow-MMU-Zustand (Tainted: G W) weiter.

Eine überlebende Warnung bedeutet nicht, dass Sicherheit gegeben ist. Sie bedeutet, dass der vom Host verwaltete Übersetzungszustand inkonsistent geworden ist und die Maschine ihre eigene Assertion nur knapp überstanden hat. Für eine kontrollierte Erfassung von Crash-Dumps können Sie Reproduktionen der Warnungsklasse als schwerwiegende Fehler behandeln:

sudo sysctl kernel.panic_on_warn=1

Das ist eine Test- und vmcore-Hilfe. Es handelt sich nicht um eine Abhilfemaßnahme.

Was sich durch den Upstream-Fix ändert

Der Fix fügt die fehlende Rollenprüfung hinzu, bevor KVM eine Schattenseite wiederverwendet. Vor dem Patch konnte bereits eine übereinstimmende Gast-Frame-Nummer ausreichen, um eine vorhandene Seite zu akzeptieren. Danach vergleicht `kvm_mmu_get_child_sp()` die vollständige Rolle der Seite (role.word) mit der Frame-Nummer und verwendet eine Seite nur dann wieder, wenn beide übereinstimmen. Wenn die Rolle inkompatibel ist, löscht KVM den bestehenden Eintrag und erstellt die korrekte Schattenseite, anstatt eine veraltete Interpretation weiterzuführen. Die KVM-Betreuer Paolo Bonzini und Sean Christopherson haben den Patch verfasst.

Konzeptionell:

Before:  matching gfn → reuse shadow page → role mismatch ignored → stale reverse map → use-after-free
After:   matching gfn → compare role.word → reject incompatible page → zap old entry → build correct page

Der Januscape-Fix im Upstream ist der Commit 81ccda30b4e83d8f5cc4fd50503c44e3a33abfeb. Die dazugehörige Korrektur für CVE-2026-46113 ist der Commit 0cb2af2ea66ad8ff195c156ea690f11216285bdf. Da jede dieser Korrekturen eine andere „stale-shadow-page“-Situation behebt, gehören beide in einen gepatchten Kernel.

In den Aufzeichnungen der Anbieter und zu „rebootless-patch“ werden diese nicht immer separat gekennzeichnet. Einige frühere KernelCare-Builds enthielten die Korrektur für die Januscape-Rolle als nicht mit einer CVE-Nummer versehenen Begleitkomponente unter der Kennung CVE-2026-46113; daher bedeutet das Fehlen einer eigenständigen Zeichenfolge „CVE-2026-53359“ an sich noch nicht, dass die Korrektur für die Rolle fehlt.

The Sibling: CVE-2026-46113

Januscape trat nicht isoliert auf. Bevor es behoben wurde, schlossen die Kernel-Entwickler CVE-2026-46113, eine weitere „Use-after-free“-Schwachstelle im Zusammenhang mit KVM/x86-Shadow-Paging im selben Bereich der MMU. Die beiden Schwachstellen sollten gemeinsam erörtert, aber keinesfalls miteinander verwechselt werden, da die beiden Korrekturen unterschiedliche Sicherheitslücken beheben und ein Host beide benötigt.

CVE-2026-46113 tritt auf, wenn KVM eine Schattenseite wiederverwendet, die für eine falsche Gast-Frame-Nummer erstellt wurde. Eine Gastzuordnung ändert sich zwischen VM-Einträgen, KVM verwendet weiterhin eine Schattenseite, die für die ursprüngliche Zuordnung erstellt wurde, und ein neuer Seitentabelleneintrag wird unter einem Frame außerhalb des Bereichs gespeichert, den KVM später während der Bereinigung durchsucht. Die Bereinigung übersieht diesen Eintrag. Die Schattenseite wird freigegeben. Der veraltete Reverse-Map-Eintrag bleibt bestehen. Bei einem späteren Durchlauf der Reverse-Map wird auf die freigegebene Seite verwiesen.

Der Fix für CVE-2026-46113 (Commit 0cb2af2ea66a) fügte eine Überprüfung der Gast-Frame-Nummer hinzu: Wenn KVM feststellt, dass eine vorhandene Seite zum falschen Frame gehört, löscht es den alten Eintrag, anstatt ihn wiederzuverwenden. Januscape zeigte, dass diese Überprüfung nicht ausreichte.

Im Januscape-Pfad kann die Frame-Nummer korrekt erscheinen. Die Diskrepanz liegt in der Rolle der Schattenseite:

Die ursprüngliche Zuordnung erstellt eine direkte Schattenseite für eine große Zuordnung von 2 MB (direct=1).
Der Gast ändert diese Zuordnung so, dass sie auf eine untergeordnete Seitentabelle verweist.
Der neue Pfad benötigt eine indirekte Schattenseite für 4-KB-Zuordnungen (direct=0).
KVM findet eine passende Frame-Nummer und verwendet die alte Seite erneut.
Der Rahmen stimmt überein, die Darstellung der Seite jedoch nicht.

CVE-2026-46113 hat den Fall des falschen Frames behoben. Januscape hat den Fall der falschen Rolle behoben. Die frühere Korrektur dient als Hintergrund; Januscape ist die Sicherheitslücke, um die es in diesem Artikel geht. Die Installation des früheren Patches allein reicht nicht aus, um Januscape zu beheben.

Wer ist betroffen?

Januscape betrifft Linux-Systeme, die die KVM/x86-Shadow-MMU nutzen. Dazu gehören sowohl Intel- als auch AMD-Hosts, da sich der anfällige Code in der gemeinsamen KVM/x86-MMU-Logik befindet und nicht ausschließlich in „kvm_intel“ oder „kvm_amd“. Der Forscher demonstrierte denselben Auslöser auf beiden Hosts, wobei er lediglich die architektur-spezifischen Page-Table-Bits vertauschte. Mehrere Faktoren entscheiden darüber, wie anfällig ein bestimmter Host ist.

KVM-Hypervisoren, auf denen Gäste mit verschachtelter Virtualisierung laufen. Höchste Priorität. Ein bösartiger oder kompromittierter Gast mit Root-Rechten in seiner eigenen VM kann über die verschachtelte Virtualisierung den anfälligen Host-Kernel-Pfad erreichen. Dies ist das „Guest-to-Host“-Escape-Szenario, bei dem eine einzelne gemietete Instanz den physischen Host zum Absturz bringen oder – mit dem zurückgehaltenen Exploit – andere Gäste auf demselben Server übernehmen kann. In unserem Labor lädt die Reproduktion im Gast ein Modul, das den Raw-VMX/SVM-Zustand steuert – genau das ist der Pfad der verschachtelten Virtualisierung.

KVM-Hosts, auf denen Gäste laufen, die jedoch keine verschachtelte Virtualisierung zulassen. Geringeres Risiko im „Gast-zu-Host“-Vektor, da die Software-Shadow-MMU für diese Gäste nicht zwangsweise zum Einsatz kommt. Vergewissern Sie sich, dass die verschachtelte Virtualisierung tatsächlich deaktiviert ist, bevor Sie sich darauf verlassen.

Hosts, auf denen KVM verfügbar ist, auf denen jedoch keine virtuellen Maschinen laufen. Diese können dennoch einen lokalen Pfad offenlegen, wenn ein nicht vertrauenswürdiger lokaler Benutzer /dev/kvm öffnen und KVM direkt steuern kann. Wenn KVM nicht genutzt wird, sollten die Module entladen und gesperrt werden.

Container und CloudLinux LVE. Ein normaler Container verfügt nicht automatisch über KVM-Zugriff. Container- und LVE-Umgebungen sind nicht allein deshalb anfällig, weil sie sich einen Host-Kernel teilen. Die Anfälligkeit hängt davon ab, ob der Container auf /dev/kvm zugreifen, QEMU steuern oder verschachtelte Virtualisierung nutzen kann. Wir haben diese Umgebungen nicht getestet und stufen sie nicht pauschal als sicher ein. Überprüfen Sie die tatsächliche Geräte- und Berechtigungskonfiguration.

Enterprise-Kernel-Versionen. Lassen Sie die Betroffenheit nicht allein anhand von „uname -r“ beurteilen. Bei Enterprise-Distributionen werden KVM-Änderungen in ältere Baselines zurückportiert, sodass ein auf 5.14 basierender EL9-Kernel die betroffene MMU-Logik enthält, während ein numerisch neuerer Kernel möglicherweise bereits über einen gezielten Backport verfügt. Überprüfen Sie den Hersteller-Fix, die Abdeckung durch KernelCare oder das Quellcode-Muster, um den genau laufenden Kernel zu ermitteln.

Die Versionsfalle läuft hier andersherum als üblich. Es heißt nicht: „Unser Kernel ist zu alt“, sondern: „Unsere Hardware ist zu neu.“ Ein Host auf EPT oder NPT wirkt modern und sicher – bis er verschachtelte Virtualisierung offenlegt und Gäste unbemerkt zurück durch 16 Jahre alten Shadow-MMU-Code leitet. Man sollte sich nach dem richten, was der Host offenlegt, und nicht nach dem Silizium, auf dem er läuft.

Überprüfen Sie die Angriffsfläche des KVM

Überprüfen Sie, ob die KVM-Module geladen sind:

lsmod | grep -E '^kvm|kvm_(intel|amd)'

Überprüfen Sie, ob das KVM-Gerät vorhanden ist und wer darauf zugreifen kann:

ls -l /dev/kvm

Auf aktive QEMU/KVM-Workloads prüfen:

pgrep -a -f 'qemu-system|qemu-kvm'

Überprüfen Sie, ob die verschachtelte Virtualisierung aktiviert ist:

cat /sys/module/kvm_intel/parameters/nested   # Intel
cat /sys/module/kvm_amd/parameters/nested      # AMD

Für von libvirt verwaltete Hosts:

virsh list --all

Diese Befehle geben Auskunft darüber, ob KVM verfügbar ist, verwendet wird und verschachtelte Virtualisierung unterstützt. Sie liefern jedoch keinen Nachweis dafür, ob Januscape gepatcht ist.

Jetzt Maßnahmen ergreifen

Hier gibt es echte Konfigurationsmaßnahmen zur Risikominderung, und jede davon schließt einen bestimmten Angriffsvektor ab. Keine davon schließt alle ab, und genau darum geht es ja.

Hosts, auf denen keine VMs ausgeführt werden. Wenn das System KVM nicht benötigt, laden Sie die Module aus und verhindern Sie deren Laden. Verwenden Sie „install … /bin/false“ anstelle einer einfachen Blacklist-Zeile, da „blacklist“ allein ein explizites oder durch Abhängigkeiten bedingtes Laden nicht verhindert.

# unload now (fails if a VM is running, in which case this host isn't a candidate)
sudo modprobe -r kvm_intel kvm      # kvm_amd on AMD hardware

# prevent load on boot
printf 'install kvm_intel /bin/false\ninstall kvm_amd /bin/false\n' \
| sudo tee /etc/modprobe.d/disable-kvm.conf

Überprüfen Sie, ob der Befehl „lsmod | grep kvm“ keine Ergebnisse liefert und „ls /dev/kvm“ meldet, dass keine solche Datei vorhanden ist. Um den Vorgang rückgängig zu machen, löschen Sie die Datei „/etc/modprobe.d/disable-kvm.conf“ und führen Sie „modprobe kvm_intel“ (oder „kvm_amd“) aus, oder starten Sie den Rechner neu.

Hosts, auf denen virtuelle Maschinen laufen, die jedoch keine verschachtelte Virtualisierung benötigen. Dies ist die wirksamste Abhilfemaßnahme, die ohne den Patch möglich ist. Durch das Deaktivieren der verschachtelten Virtualisierung wird der Pfad vom Gast zum Host unterbunden, da die Schatten-MMU nur bei verschachtelten Gästen zum Einsatz kommt:

# Intel
echo 'options kvm_intel nested=0' | sudo tee /etc/modprobe.d/disable-nested-virt.conf
# AMD
echo 'options kvm_amd nested=0' | sudo tee /etc/modprobe.d/disable-nested-virt.conf

Die Änderung wird wirksam, nachdem das KVM-Modul neu geladen wurde (wobei keine virtuellen Maschinen laufen dürfen) oder nach einem Neustart. Überprüfen Sie dies mit dem Befehl „cat /sys/module/kvm_intel/parameters/nested“, der den Wert „N“ oder „0“ zurückgeben sollte.

Hosts der RHEL-Familie, auf denen virtuelle Maschinen und verschachtelte Virtualisierung laufen müssen. Bei diesen Distributionen ist /dev/kvm für alle zugänglich (Modus 0666), wodurch ein lokaler Benutzer ohne Sonderrechte den Fehler direkt ausnutzen kann. Verschärfen Sie die Berechtigungen:

echo 'KERNEL=="kvm", GROUP="kvm", MODE="0660"' \
| sudo tee /etc/udev/rules.d/65-kvm.rules
sudo udevadm control --reload-rules
sudo udevadm trigger --name-match=kvm

Überprüfen Sie dies mit dem Befehl „ls -l /dev/kvm“ und „getent group kvm“ und fügen Sie nur Konten, die KVM benötigen, zur Gruppe „kvm“ hinzu. Dadurch wird der „unprivileged-local“-Vektor geschlossen. Dies hindert jedoch keinen böswilligen Gast daran, über seinen autorisierten QEMU-Prozess auf die Shadow-MMU zuzugreifen – unabhängig von den Berechtigungen der Host-Geräte.

Entscheidungsmoment. Wenn auf einem Host keine Gäste laufen, deaktivieren Sie KVM und sperren Sie den Zugriff darauf. Wenn Gäste laufen, die keine verschachtelte Virtualisierung benötigen, deaktivieren Sie diese jetzt und führen Sie Patches in Ihrem üblichen Rhythmus durch. Wenn nicht vertrauenswürdige Gäste laufen und verschachtelte Virtualisierung benötigt wird – Multi-Tenant-Cloud, Hosting, CI, das verschachtelte VMs erstellt –, bietet keine Konfigurationsänderung vollständigen Schutz; verschieben Sie daher einen Patch ohne Neustart oder einen korrigierten Kernel an den Anfang der Warteschlange. Und betrachten Sie eine Reproduktion, die lediglich eine Warnung auslöst, als Bestätigung einer Sicherheitslücke und nicht als Beweis für Sicherheit.

Erkennung

Januscape hinterlässt keine verlässlichen Spuren auf der Festplatte. Die Manipulation findet im Speicher des Host-Kernels statt, während KVM die Schatten-Seitentabellen und umgekehrten Zuordnungen verwaltet, sodass Tools zur Dateiintegritätsprüfung auch nach Auslösung des anfälligen Zustands keine Anomalien anzeigen. Dadurch wird die Erkennung auf Verhaltensmerkmale verlagert, und jeder der folgenden Punkte ist ein Hinweis, kein Beweis.

Kernel-Fehler oder Warnungen in arch/x86/kvm/mmu/mmu.c, insbesondere im Zusammenhang mit pte_list_remove().
GFN-Mismatch-Meldungen oder Warnungen von `kvm_mmu_page_set_translation()` – die Verwechslung von Rolle und Frame wird bereits vor dem Freigabevorgang sichtbar.
Der Host gerät in Panik oder stürzt wiederholt ab, während qemu-kvm oder qemu-system-* aktiv ist, ohne dass ein entsprechender Hardwarefehler vorliegt.
Ein Kernel, der nach einer KVM-MMU-Warnung den Status „W“ erhalten hat.
Verschachtelte Virtualisierungsaktivitäten an unerwarteten Stellen oder Zugriffe auf /dev/kvm durch ungewöhnliche Konten oder Prozesse.
Ein lokales Host-Konto oder ein lokaler Host-Dienst, der kurz nach einer Phase der Instabilität der KVM-MMU erweiterte Berechtigungen erlangt, ohne dass ein entsprechendes „sudo“- oder Anmeldeereignis vorliegt.

Die letzten Kernel-Meldungen anzeigen:

journalctl -k --since "24 hours ago" \
| grep -Ei 'kvm|mmu|gfn|pte_list_remove|BUG|WARNING'

Überprüfen Sie den aktuellen Boot-Vorgang:

dmesg -T | grep -Ei 'kvm|mmu|gfn|pte_list_remove|BUG|WARNING'

Das Fehlen dieser Meldungen ist kein Beweis dafür, dass der Host gepatcht ist. Ein Angreifer kann es vermeiden, die Konsistenzprüfung auszulösen, und ein anfälliger Pfad wurde möglicherweise einfach noch nicht genutzt. Wenn auf einem exponierten Host nicht vertrauenswürdige Gäste laufen und Sie Instabilitäten bei KVM-MMU feststellen, sollten Sie den Host genauer unter die Lupe nehmen – neue Konten, geänderte Authentifizierungskonfiguration, unerwartete Dienste auf dem Host –, anstatt die fehlerfreien Hashes der Gastdateien als Beweis dafür zu werten, dass der Host in Ordnung ist.

Warum Januscape wichtig ist

Januscape stellt eine ganz andere Problemklasse dar als ein lokaler Kernel-Privilegieneskalationsfehler. Bei einer herkömmlichen lokalen LPE muss der Angreifer bereits über Codeausführung auf dem Host verfügen. Ein „Guest Escape“ geht von Code aus, dessen Ausführung die Organisation bewusst innerhalb einer VM zugelassen hat, in der Annahme, dass KVM diesen Code eindämmen würde. Diese Annahme zu widerlegen, ist der Kern des Ganzen.

Deshalb trifft dies am stärksten dort zu, wo die Isolierung von Gästen das Kernprodukt ist: öffentliche und private Clouds, Hosting-Anbieter, Multi-Tenant-Cluster, CI- und Build-Infrastrukturen, Sicherheitsforschungsumgebungen, Entwickler-Clouds sowie jede Plattform, auf der vom Kunden kontrollierte VMs laufen. Das Alter der zugrunde liegenden Annahme verstärkt dies noch. Das Verhalten lässt sich bis ins Jahr 2010 zurückverfolgen und hat sich über viele Generationen von Unternehmens-Kerneln hinweg fortgesetzt, sodass die Aussage „Wir nutzen eine moderne Distribution“ keine Rechtfertigung darstellt.

Der Grund, warum man sich hier leicht täuschen lässt, ist zugleich der Grund, warum es gefährlich ist. Drei plausible Signale deuten alle auf „Sicherheit“ hin und führen doch in die Irre. Die Hardware-EPT oder NPT vermittelt den Eindruck, als hätte sie die Schatten-MMU außer Kraft gesetzt, doch die verschachtelte Virtualisierung zieht die Gäste direkt wieder zurück in diese. Der GFN-Fix (CVE-2026-46113) scheint diesen Teil der MMU geschlossen zu haben, doch er hat lediglich die andere Hälfte des Fehlers behoben und den Rollenfall offen gelassen. Und ein PoC, der nur einen eigenen Rechner zum Absturz bringt, wirkt wie ein harmloser Selbst-DoS, obwohl der Absturz eher die öffentliche Demonstration als die Obergrenze darstellt. Vertraut man auch nur einem davon, stuft man einen anfälligen Host fälschlicherweise als sicher ein.

Der Zusammenhang mit CVE-2026-46113 ist die größte Quelle für falsches Vertrauen. Ein Team, das den früheren „unexpected-GFN“-Use-after-Free-Fehler behoben hat, könnte zu dem Schluss kommen, dass das Shadow-Paging-Problem damit gelöst ist. Das ist jedoch nicht der Fall. Der frühere Fix überprüfte, ob KVM den richtigen Frame gefunden hatte. Januscape zeigte, dass KVM zusätzlich überprüfen musste, ob es die richtige Art von Shadow-Page gefunden hatte. Eine Übereinstimmung reichte nicht aus, und ein geschlossener CVE-Eintrag bedeutet nicht, dass beides behoben ist.

Checkliste für priorisierte Sanierungsmaßnahmen

Verfolge dies unter der Kennung CVE-2026-53359 (Januscape), nicht unter CVE-2026-46113.
Stellen Sie sicher, dass auf den betroffenen Hosts sowohl der Januscape-Fix als auch der zugehörige CVE-2026-46113-Fix installiert sind. Beide sind erforderlich.
Erstelle eine Bestandsliste der Hosts, auf denen KVM-Module geladen sind, /dev/kvm vorhanden ist oder aktive QEMU-Workloads laufen, und kennzeichne diejenigen, die verschachtelte Virtualisierung ermöglichen.
Priorisieren Sie Multi-Tenant-Hosts sowie alle Hosts, auf denen nicht vertrauenswürdige Gäste mit aktivierter verschachtelter Virtualisierung laufen.
Deaktivieren Sie KVM vollständig auf Hosts, die keine Virtualisierung nutzen.
Deaktivieren Sie verschachtelte Virtualisierung, wo sie nicht benötigt wird – dadurch wird der Fluchtweg für nicht vertrauenswürdige Gäste unterbunden.
Beschränken Sie den Zugriff auf /dev/kvm auf vertrauenswürdige Konten und die Gruppe „kvm“ auf Hosts der RHEL-Familie. Dies verhindert lediglich Angriffe durch lokale Benutzer ohne Sonderrechte, nicht jedoch durch böswillige Gäste.
Überprüfen Sie AMD-Hosts ausdrücklich – diese sind auch dann betroffen, wenn ein Test ausschließlich mit Intel-Systemen keine Fehler gemeldet hat.
Leiten Sie keine Rückschlüsse auf die Sicherheit allein aus der Kernel-Version ab, und behandeln Sie eine Reproduktion, bei der lediglich eine Warnung auftritt, als Sicherheitsrisiko.
Suchen Sie nach KVM-GFN-Warnungen, Fehlern bei `pte_list_remove()` und unerklärlichen Host-Panics, und betrachten Sie fehlerfreie Gastdatei-Hashes nicht als ausreichenden Beweis für den Host.
Wenden Sie einen festen Hersteller-Kernel an und starten Sie den Rechner neu, oder verwenden Sie den „KernelCare“-Patch ohne Neustart für den aktuell ausgeführten Kernel, wobei Sie den Hosts Vorrang einräumen sollten, bei denen ein Neustart am schwierigsten ist.
Überprüfen Sie die explizite CVE-Abdeckung für beide Korrekturen, anstatt sich auf die Erstellungsdaten zu verlassen.

Rebootloses Patchen

Januscape ist die Art von Hypervisor-Fehler, die noch lange nach der Veröffentlichung eines korrigierten Pakets bestehen bleibt. Die Installation des Pakets ist nur der erste Schritt. Der Host muss noch in den Ersatzkernel booten, und in einem KVM-Cluster bedeutet das, Knoten zu entlasten, Gäste zu migrieren, Mandanten zu koordinieren, Kapazitätsreserven vorzuhalten und Maschinen im Rahmen der Wartung auszutauschen. Diese Einschränkungen können eine bekannte Sicherheitslücke bei Gästen auf Wochen oder Monate der verbleibenden Gefährdung ausdehnen, und sie belasten gerade die Multi-Tenant-Hosts am stärksten, die am meisten gefährdet sind.

Die Änderung eignet sich gut als „Rebootless-Patch“: eine kleine Korrektur im MMU-Fehler- und Reverse-Map-Pfad, bei der kein dauerhafter Zustand übertragen werden muss. KernelCare portiert beide erforderlichen Korrekturen – die Januscape-Rollenkorrektur (81ccda30b4e8) und die dazugehörige GFN-Korrektur (0cb2af2ea66a) – gemeinsam in den laufenden Kernel, mit Varianten pro Kernel-Familie für die EL 5.14-Backport-Linien und die auf der Mainline basierenden 6.x-Kernel. LibCare findet keine Anwendung, da es sich um einen reinen Kernel-Fehler ohne Komponente in der Userspace-Bibliothek handelt.

Stand der Veröffentlichung: 29. Juli 2026.

KernelCare liefert den „Januscape“-Rollen-Fix und den erforderlichen Begleit-Fix für CVE-2026-46113 gemeinsam aus, sodass die Verfügbarkeit pro Kernel-Familie und nicht pro CVE angegeben wird.

Stabil, vollständig eingeführt

RHEL 10 – Patchset K20260703_15

Oracle Linux 10 – K20260703_16

Rocky Linux 10 – K20260703_17

AlmaLinux 10 – K20260703_18

Debian 13 – K20260706_09

Ubuntu 22.04 – K20260706_01 (_02 für arm64, _03 für Azure, _04 für AWS)

Ubuntu 20.04 mit dem Jammy-HWE-Kernel – K20260706_06 (Azure: _05, AWS: _07)

Ubuntu 24.04 – K20260707_01 (AWS: _02)

Proxmox VE 7 (5.15) – K20260706_08

Proxmox VE 8 (6.8) – K20260707_03

Enterprise Linux 9, veröffentlicht im Juli 2026

RHEL 9 – K20260710_58

AlmaLinux 9 und CloudLinux 9 – K20260710_60

Oracle Linux 9 – K20260710_63

Rocky Linux 9 – K20260710_65

Schrittweise Einführung

Debian 12 – K20260709_25

Debian 11 – K20260710_11

Ubuntu 20.04 Standard-Kernel – K20260710_10

CloudLinux 8 – K20260709_27

Im Test

RHEL 8 – K20260710_31

AlmaLinux 8 – K20260710_41

Rocky Linux 8 – K20260710_43

CentOS 8 – K20260710_33

Oracle Linux 8 – K20260710_35

CloudLinux 7 Hybrid – K20260710_39

Noch offen

Oracle UEK6, Oracle UEK7, Amazon Linux 2, Ubuntu 18.04.

Enterprise Linux 7 ist betroffen, es ist jedoch kein Patch geplant. Die praktischen Auswirkungen beschränken sich hier auf einen Denial-of-Service-Angriff: Ein DoS-Angriff vom Mandanten auf den Host ist nicht praktikabel, da verschachteltes VMX langsam genug ist, um den Race-Zustand unzuverlässig zu machen, und der lokale Pfad zur Rechteausweitung durch CONFIG_BUG_ON_DATA_CORRUPTION gesperrt ist. Hosts unter EL7 sollten dennoch die oben genannten Konfigurationsmaßnahmen zur Risikominderung anwenden.

Die Unterstützung für Enterprise Linux 9 ist nun für RHEL 9, AlmaLinux 9 und CloudLinux 9, Oracle Linux 9 sowie Rocky Linux 9 verfügbar. Das ist wichtig, da EL9 die Plattform ist, auf der in unserem Labor ein schwerwiegender Host-Panic aufgetreten ist; daher müssen exponierte EL9-Hosts weiterhin als Erstes gepatcht werden – sie müssen jedoch nicht mehr auf Konfigurationsmaßnahmen angewiesen sein, während sie auf die Veröffentlichung eines Patches warten. Die verbleibenden, noch nicht abgedeckten Plattformen sind Oracle UEK6 und UEK7, Amazon Linux 2 sowie Ubuntu 18.04; diese Hosts sind weiterhin auf die oben genannten Abhilfemaßnahmen oder einen korrigierten Hersteller-Kernel angewiesen.

Aus dem Test-Feed bewerben:

sudo kcarectl --update --prefix test

Nach der Freigabe aus dem Produktions-Feed anwenden:

sudo kcarectl --update

Überprüfen Sie den laufenden Patch-Build:

kcarectl --info | grep kpatch-build-time      # build dated 2026-07 or later

Da Januscape beide Korrekturen benötigt, sollten Sie überprüfen, ob beide vorhanden sind, anstatt sich auf ein Datum zu verlassen:

kcarectl --patch-info | grep -E

'CVE-2026-53359|CVE-2026-46113'

Zwei Treffer sind eine eindeutige Antwort. Ein Treffer bei CVE-2026-46113 allein ist aufgrund der zuvor erwähnten Historie der Kennzeichnung kein Beweis dafür, dass die Rollenkorrektur fehlt – überprüfen Sie in diesem Fall das installierte K-Tag anhand der obigen Release-Liste oder des KernelCare-Abdeckungsdatensatzes für diese Kernel-Familie. Ein Build-Datum allein beweist nichts. Ein nach Mitte Juni kompilierter Kernel enthält nicht automatisch diesen Fix, und es ist nicht garantiert, dass beide Fixes vorhanden sind. Überprüfen Sie die CVE-Zuordnung, den K-Tag, das Erratum des Anbieters oder direkt den Quellcode.

Januscape verwandelt eine geringfügige Diskrepanz zwischen KVM-Shadow-Page und Gast-Host-Grenze in einen Fehler an dieser Grenze. Für Virtualisierungsumgebungen, die Notfall-Neustarts nicht verkraften können, schließt ein Patch ohne Neustart diese Lücke im laufenden Kernel, ohne jeden Knoten herunterfahren oder die darauf laufenden Gäste unterbrechen zu müssen.

Holen Sie sich KernelCare noch heute →