Dieses Dokument beschreibt die von Hyunwoo Kim (@v4bel) gemeldete und gepatchte Schwachstelle ITScape (CVE-2026-46316). Es handelt sich um eine KVM-Escape-Sicherheitslücke, die es einem Gast ermöglicht, in einer KVM/arm64-Umgebung auf den Host zu entkommen und dort Befehle mit Kernel-(Root-)Rechten auszuführen. Nach öffentlichem Kenntnisstand ist dies die erste Exploit-Forschung zum Guest-to-Host-Escape, die auf KVM/arm64 abzielt.
ITScape nutzt eine Race Condition in der Emulation von vGIC-ITS (Interrupt Translation Service) unter KVM/arm64 aus. Die Schwachstelle wird allein durch Aktionen auf der Gästeseite ausgelöst, um zum Host zu entkommen, und sie kann die Gast-Host-Isolation von KVM/arm64-Hosts gefährden, die nicht vertrauenswürdige Gäste akzeptieren, insbesondere arm64-Public-Clouds mit mehreren Mandanten.
Im Gegensatz zu den allgemein veröffentlichten QEMU-Escapes liegt der Fehler im In-Kernel-KVM und nicht im QEMU-Benutzerraum, sodass er unabhängig von der QEMU-Emulation funktioniert und auf dem Host Befehle mit Host-Kernel-Rechten ausführen kann, anstatt mit den Rechten eines Benutzerprozesses (wie QEMU).
Für die detaillierten technischen Informationen siehe hier.
[!NOTE] Nach der Meldung dieser Schwachstelle an [email protected] ist die vereinbarte Embargofrist abgelaufen, sodass dieses ITScape-Dokument nun veröffentlicht wird. Den Offenlegungszeitplan finden Sie im technischen Detaildokument.
Für sichere Tests wird empfohlen, den PoC unter QEMU TCG auszuführen. (Das Auslösen der Schwachstelle hat nichts mit QEMU zu tun.) Wenn der PoC unter QEMU TCG ausgeführt wird, ergibt sich die folgende Struktur.
QEMU TCG: emulates an arm64 CPU (including EL2) so an arm64 kernel runs as the KVM host
└─ arm64 Host Kernel: the KVM host and the escape target
└─ poc: opens the HOST's /dev/kvm and creates one guest VM "G" (uid=1000)
└─ 1. G's guest code (run by poc via KVM_RUN) performs GIC/ITS MMIO
2. traps into the HOST's in-kernel KVM -> double-put -> HOST kernel code-exec
Dieser PoC ist kein vollständig weaponisierter Exploit, der sofort in einer arm64-Cloud-Umgebung ausgeführt wird, sondern Demonstrationscode, der die Schwachstelle und die vollständige Exploit-Kette auf Grundlage eines kvm-Selftests reproduziert. Ein Angreifer, der die Implementierung des Virtualisierungs-Stacks der Ziel-Cloud kennt, dürfte den Übergang zur Weaponisierung selbst nicht als schwierig empfinden; es erfordert jedoch, die hostseitige direkte Konstruktion des Selftests auf einen realen, vom Gast gesteuerten Pfad zu übertragen und die Adressen, Gadgets, Offsets, das Race-Timing usw. auf die Ziel-Kernelversion und -Konfiguration abzustimmen. Ein weaponisierter Exploit für reale Umgebungen existiert, wird aber nicht veröffentlicht.
# ./build.sh <linux>/tools/testing/selftests/kvm
# ./qemu.sh <kernel-image> <initramfs>
# ./poc
...
[+] /ITScape created by the host kernel (owner uid=0). verify: ls -la /ITScape
# ls -la /ITScape
-rw-r--r-- 1 0 0 0 Jun 9 00:02 /ITScape
Dieser PoC dient dazu, genaue Informationen bereitzustellen. Verwenden Sie ihn nicht auf Systemen, die Sie nicht testen dürfen.
ITScape (CVE-2026-46316) umfasst den Bereich von 8201d1028caa (2024-04-25) bis 13031fb6b835 (2026-06-05).
Wenn Sie einen arm64-KVM-Host betreiben, der Multi-Tenant-Gäste akzeptiert, oder eine Instanz auf einem solchen Host nutzen, prüfen Sie, ob der Patch 13031fb6b835 auf den Host-Kernel angewendet wurde (Betreiber direkt, Mieter über ihren Anbieter). Da es sich außerdem um eine neue Schwachstellenklasse handelt, sind weitere Varianten und Folge-Schwachstellen zu erwarten; behalten Sie das also im Auge. Sie müssen jedoch unterscheiden, ob eine Folge-Schwachstelle wirklich allein durch Gast-Aktionen ohne hostseitige Aktionen auslösbar ist und ob sie tatsächlich ausnutzbar ist.
Nein. Die Schwachstelle befindet sich in arch/arm64/kvm/vgic/. Wenn Sie keinen arm64-KVM-Host verwenden, müssen Sie sich um diese Schwachstelle keine Sorgen machen.
Ja. Das Ansteuern der GIC/ITS-MMIO erfordert Gast-Kernel-Rechte (EL1). Wenn Ihnen in einer Public Cloud eine Instanz zugewiesen wird, haben Sie in der Regel Root-Rechte auf Ihrer eigenen VM, sodass diese Anforderung erfüllt ist. In einem Szenario ohne Root auf dem Gast muss sie mit einem LPE wie Dirty Frag verkettet werden.