Security 07.08.2026, 02:42 Aktualisiert: 07.08.2026, 02:42

ITScape CVE-2026-46316: Die ARM64-VM übernimmt den KVM-Host

ITScape ist ein ARM64-KVM-Escape mit öffentlicher Root-Kette. Betroffene Kernel, Distro-Patches, Voraussetzungen, Prüfungen und Mitigation.

Von Moritz Mantel · Veröffentlicht: 07.08.2026, 02:42 · Aktualisiert: 07.08.2026, 02:42

Stand: 07.08.2026, 02:42 Uhr CEST. Die großen Distributionen haben ihre regulären ARM64-Kernel überwiegend aktualisiert oder als nicht betroffen eingeordnet. Cloud-, HWE-, RT- und Appliance-Kernel müssen trotzdem einzeln geprüft werden.

Kurzfassung

CVE-2026-46316, ITScape: ein Double-put mit anschließendem Use-after-free in der virtuellen GICv3-ITS-Emulation von KVM auf ARM64.
Auswirkung: Der öffentliche KVM-Selftest zeigt eine vollständige Root-Kette und erzeugt auf dem Host /ITScape mit UID 0. Für einen Angriff aus einer normalen Cloud-VM muss diese Kette erst in Gast-Kernelcode portiert werden.
Voraussetzungen: ARM64-KVM-Host, verwundbarer Host-Kernel, virtuelle GICv3 ITS, mindestens zwei vCPUs und Kernelrechte im Gast.
Besonders unangenehm: ITScape braucht keine Nested Virtualization. Normale ARM64-VMs können den verwundbaren KVM-Pfad erreichen.
Nicht betroffen: x86-KVM. Offizielles Proxmox VE läuft nur auf Intel 64 beziehungsweise AMD64 und ist damit nicht betroffen. Community-Ports auf ARM müssen ihren Kernel separat prüfen.
Nicht der Fix: Weder ein QEMU-Update noch ein neuer Gast-Kernel beseitigen die Lücke im Host-Kernel.
Sofortmaßnahme: Host-Kernel auf einen belegten Vendor-Fix aktualisieren und neu starten. Ohne verfügbaren Fix sollten nicht vertrauenswürdige VMs auf gepatchte Hosts migriert oder vorübergehend gestoppt werden.

ITScape-Demo: Der PoC erzeugt als Root die Datei /ITScape auf dem ARM64-KVM-Host

Demo und Exploit: Hyunwoo Kim / V4bel. Das GIF zeigt den veröffentlichten KVM-Selftest in einer kontrollierten Umgebung.

Die KVM-Escape-Trilogie

ITScape ist der ARM64-Teil einer Reihe technisch verschiedener KVM-Escapes. Januscape und Zapscape greifen die x86-Shadow-MMU bei Nested Virtualization an. ITScape sitzt dagegen in der ARM64-Interruptvirtualisierung. Nested KVM spielt hier keine Rolle.

Nach öffentlich bekanntem Stand ist ITScape der erste veröffentlichte Guest-to-Host-Exploit, der direkt auf das In-Kernel-KVM von ARM64 zielt. Für Betreiber zählt vor allem: Der Gast erreicht den Use-after-free im Host-Kernel, ohne zuerst einen zweiten Hypervisor starten zu müssen.

Was ist ITScape?

ARM64-Systeme verwenden den Generic Interrupt Controller, kurz GIC. GICv3 kann sogenannte LPIs verwalten. Das sind Interrupts, die etwa durch PCIe-Geräte und Message Signaled Interrupts entstehen. Der optionale Interrupt Translation Service, ITS, übersetzt dafür ein Paar aus DeviceID und EventID in den passenden Interrupt und die Ziel-vCPU.

KVM emuliert diesen ITS für eine virtuelle Maschine im Host-Kernel. Befehle wie MAPD, MAPTI oder INT und Zugriffe auf die GIC-Register landen deshalb direkt in arch/arm64/kvm/vgic/vgic-its.c. QEMU reicht die VM zwar an KVM durch, verarbeitet den verwundbaren Pfad aber nicht selbst.

Der Fehler wurde mit Commit 8201d1028caa eingeführt und ist seit Linux 6.10 vorhanden. Vendor-Kernel können den Code zurückportiert haben. Deshalb gilt auch hier: Die sichtbare Versionsnummer ist nur ein erster Hinweis, ein Hersteller-Advisory ist der bessere Beleg.

Wie aus einem doppelten Put ein Host-Escape wird

KVM hält für jedes virtuelle ITS einen XArray-Cache. Ein Eintrag ordnet (DeviceID, EventID) einem vgic_irq zu. Der Cache besitzt genau eine Referenz auf dieses Objekt.

Mehrere Codepfade können denselben Cache leeren. Sie benutzen unterschiedliche Locks oder, beim Abschalten der LPIs über GICR_CTLR.EnableLPIs, gar keinen ITS-weiten Lock. Zwei vCPUs können deshalb gleichzeitig durch denselben VM-globalen Cache laufen.

Der alte Code rief xa_erase() auf, ignorierte aber dessen Rückgabewert. Anschließend reduzierte er die Referenz des Eintrags, den der Iterator zuvor gesehen hatte. Beobachten zwei Kontexte denselben Eintrag, entfernt nur einer ihn tatsächlich aus dem XArray-Cache. Beide führen trotzdem vgic_put_irq() aus.

Damit fällt der Referenzzähler zweimal, obwohl der Cache nur eine Referenz besaß. Das vgic_irq wird über RCU freigegeben, während ein ITE-Eintrag noch darauf zeigt. Der Gast hat nun einen Use-after-free im Host-Kernel.

Der Fix 13031fb6b835 verwendet den Wert, den xa_erase() atomar zurückgibt. Nur der Kontext, der den Eintrag wirklich entfernt hat, gibt auch dessen Referenz frei.

Die veröffentlichte Exploit-Kette

Der ITScape-PoC füllt den Translation Cache mit ungefähr 130.000 Zuordnungen. Vier vCPUs löschen anschließend möglichst gleichzeitig ihr jeweiliges GICR_CTLR.EnableLPIs. Das verlängert das Zeitfenster und erzeugt mehrere konkurrierende Cache-Drains.

Nach dem gewonnenen Race wartet der Gast die RCU-Freigabe ab und belegt die freigewordene 96-Byte-Struktur über einen guest_memfd-Cross-Cache neu. Der Gast kann die wiederverwendete Seite lesen und beschreiben. Dadurch kontrolliert er die Felder des vermeintlichen vgic_irq.

Aus diesem Fake-Objekt baut der PoC zunächst einen Leak für eine echte vCPU-Adresse und den KASLR-Slide. Danach missbraucht er einen gefälschten ops-Pointer für einen Write-what-where. Die Kette überschreibt einen verzögert ausgeführten Kernel-Work-Callback und poweroff_cmd. Am Ende startet der Host über call_usermodehelper() den vorbereiteten Befehl als Root.

Eine zweite virtuelle ITS-Instanz hält einen funktionsfähigen Befehlspfad offen, nachdem ein vCPU-Kontext beim Leak stirbt. Dahinter steckt eine ausgearbeitete Kette aus Heap-Reclaim, Informationsleck, einer Schreibprimitive und verzögerter Codeausführung.

Was der PoC beweist und was noch portiert werden muss

Die veröffentlichte Version basiert auf einem KVM-Selftest. Der Testprozess richtet VM, vCPUs, zwei ITSes, PMU und guest_memfd über Host-IOCTLs ein. In einer echten Cloud-VM hat ein Angreifer diesen direkten VMM-Zugriff nicht.

Die Auslösung selbst läuft bereits aus dem Gast: ITS-Tabellen und Command Queue befüllen, MAPD/MAPTI/INT senden, die LPIs parallel abschalten und den neu belegten Speicher benutzen. Für einen realen Angriff müssen die Selftest-Vorbereitungen in Gast-Kernelcode übertragen und Offsets, Gadgets, Timing sowie Speicher-Backend an den Zielhost angepasst werden.

Der Demo-Build verwendet vier vCPUs, zwei ITSes, 64 MiB guest_memfd, 4K-Seiten, panic_on_oops=0 und keine wirksame Forward-Edge-CFI. Andere Hostkonfigurationen verändern die Portierung. Sie machen den zugrunde liegenden Double-put nicht ungeschehen.

In den geprüften Vendor-, Researcher- und KEV-Quellen fanden wir zum genannten Stand keinen belastbaren Hinweis auf aktive Ausnutzung. CVE-2026-46316 steht auch nicht im CISA-KEV-Katalog.

Wann ein System angreifbar ist

Voraussetzung	Einschätzung
ARM64-KVM-Host	Erforderlich. Der Fehler liegt in KVM/arm64; x86 ist nicht betroffen.
Verwundbarer Host-Kernel	Entscheidend. Ein Gast-Update ändert den KVM-Code des Hosts nicht.
Virtuelle GICv3 ITS	Erforderlich, weil der Translation Cache zum ITS gehört.
Mindestens zwei vCPUs	Für den Race-Pfad nötig. Der öffentliche PoC verwendet vier.
Root oder EL1-Code im Gast	Nötig, um GIC- und ITS-MMIO gezielt zu programmieren. Bei einer gemieteten VM ist Gast-root üblich.
Nested Virtualization	Nicht erforderlich. ITScape greift eine normale KVM-VM an.
QEMU auf dem Host	QEMU ist nicht die Schwachstelle. Version und Maschinenkonfiguration können aber beeinflussen, ob ein ITS präsentiert wird.
Untrusted Multi-Tenant-VMs	Höchste Priorität. Hier kreuzen sich ein realistischer Angreifer und die volle Host-Auswirkung.

Warum die CVSS-Werte auseinanderliegen

Der Linux-CNA-Datensatz bewertet ITScape mit CVSS 9,3 und Critical. Red Hat kommt auf 7,0 und Important, SUSE auf 7,8. Ubuntu zeigt den CNA-Wert 9,3, setzt die eigene Priorität aber auf Medium.

Der Unterschied steckt vor allem in den Annahmen. Die Linux CNA zählt Rechte innerhalb einer zugewiesenen VM nicht als Hostprivileg und bewertet die Komplexität niedrig. Red Hat behandelt Gast-root als vorhandenes lokales Privileg und die Portierung als hohe Komplexität. So entstehen trotz derselben technischen Auswirkung zwei deutlich verschiedene Scores.

Für einen ARM64-Hoster ersetzt diese Diskussion keine Risikoanalyse. Wenn Kunden Root in ihren VMs haben und der Host einen verwundbaren ITS-Pfad anbietet, ist die mögliche Auswirkung vollständige Root-Ausführung auf dem Virtualisierungshost.

Patchstände nach Distribution und Plattform

Plattform	Stand am 07.08.2026, 02:42 Uhr CEST
Upstream Linux stable	Gefixt in `6.12.93`, `6.18.35` und `7.0.12`; Mainline ab 7.1 beziehungsweise `7.1-rc7`. Der Mainline-Fix ist `13031fb6b835`. Versionen vor 6.10 enthalten den ursprünglichen Upstream-Code nicht.
Debian	Bullseye und Bookworm sind nicht betroffen, weil der verwundbare Code fehlt. Trixie ist ab `linux 6.12.94-1` gefixt, im Security-Repository liegt `6.12.101-1`. Unstable ist ab `7.0.12-1` gefixt, aktuell mit `7.1.6-1`.
Ubuntu	Der Standardkernel von 26.04 ist ab `7.0.0-27.27` gefixt. Der inzwischen ausgelaufene 25.10-Zweig dokumentiert den Fix ab `6.17.0-40.40`. Ubuntu 24.04, 22.04 und 20.04 sind mit ihren Basiskerneln nicht betroffen. Noble HWE ist ab `6.17.0-40.40~24.04.1` beziehungsweise im 7.0-Zweig ab `7.0.0-28.28~24.04.1` gefixt. Cloud-Flavours haben eigene Stände, etwa AWS Resolute `7.0.0-1008.8` und Azure Resolute `7.0.0-1010.10`.
Red Hat Enterprise Linux	RHEL 10.2 ist ab `6.12.0-211.30.1.el10_2` gefixt, RHEL 10.0 EUS ab `6.12.0-55.88.1.el10_0`. RHEL 9.8 ist ab `5.14.0-687.22.1.el9_8`, RHEL 9.6 EUS ab `5.14.0-570.127.1.el9_6` abgedeckt. RHEL 8 und älter sind nicht betroffen. Für RHEL 9 RT existieren gefixte produktspezifische Builds, der generische `kernel-rt`-Status bleibt dennoch `Affected`; RHEL for NVIDIA 26 ist ebenfalls offen.
AlmaLinux	AlmaLinux 9 ist ab `5.14.0-687.22.1.el9_8`, AlmaLinux 10 ab `6.12.0-211.30.1.el10_2` gefixt. AlmaLinux 8 ist nicht betroffen.
Rocky Linux	Rocky 9 ist ab `5.14.0-687.22.1.el9_8` gefixt. Für Rocky 10 ist der Fix in den nachfolgenden 10.2-Kerneln enthalten; als belegte Untergrenze sollte mindestens `6.12.0-211.32.1.el10_2` verwendet werden. Rocky 8 ist nicht betroffen.
Oracle Linux	OL9 RHCK ist ab `5.14.0-687.22.1.el9_8` über `ELSA-2026-36018` gefixt. OL10 RHCK enthält den Backport; `ELSA-2026-39494` liefert `6.12.0-211.34.1.el10_2`. UEK R8 für OL9/10 ist ab `6.12.0-204.92.4.3.el9uek` beziehungsweise `.el10uek` gefixt. UEK- und RHCK-Zweige nicht miteinander verwechseln.
Amazon Linux	AL2 und der normale AL2023-Kernel 6.1 sind nicht betroffen. AL2023 `kernel6.12` ist ab `6.12.92-122.166.amzn2023`, `kernel6.18` ab `6.18.35-68.127.amzn2023` gefixt. Amazon veröffentlicht zusätzlich Livepatch-Advisories für mehrere ältere Paketstände.
SUSE und openSUSE	SLES 15 ist mit seinen regulären älteren Kerneln nicht betroffen. SLES 16.0 ist ab `6.12.0-160000.35.1`, SLES 16.1 ab `6.12.0-160099.45.1` gefixt. Für Leap 16.0 wurden Pakete ab `6.12.0-160000.35.1` veröffentlicht, gleichzeitig führt die Produktmatrix `kernel-source` noch als `Affected`; SUSE bewertet die CVE insgesamt weiter als `Pending`. Bei Linux Micro Extras 6.2 sind Pakete noch in Arbeit. Tumbleweed ist ab `7.0.12-1.1` abgedeckt.
Fedora	Fedora 43 ist ab `kernel-7.0.12-100.fc43`, Fedora 44 ab `kernel-7.0.12-200.fc44` gefixt. Aktuelle 7.1-Kernel enthalten den Fix ebenfalls.
Gentoo	Für Distribution-Kernel gelten die Upstream-Grenzen `6.12.93`, `6.18.35` beziehungsweise `7.0.12`. Architektur und tatsächlich gebooteten Slot prüfen.
Arch Linux	Das offizielle Arch Linux unterstützt x86_64 und ist deshalb nicht anwendbar. Arch Linux ARM ist ein eigenes Projekt und muss über dessen Kernelpakete bewertet werden.
Proxmox VE	Offizielles PVE unterstützt Intel 64 und AMD64 als Hostplattform. ITScape betrifft diese x86_64-Hosts nicht. Inoffizielle ARM-Ports wie Pimox brauchen eine eigene Kernelprüfung.

Bei Ubuntu, Oracle, SUSE und Cloud-Images reicht der Distributionsname nicht. Ein linux-aws, linux-azure, UEK-, RT- oder OEM-Kernel kann einen anderen Status als der Basiskernel haben.

Für häufige Ubuntu-ARM64-Flavours nennt Canonical folgende Mindeststände:

Ubuntu-Zweig	Ausgewählte Fixpakete
26.04	AWS `7.0.0-1008.8`, Azure `7.0.0-1010.10`, GCP und Oracle `7.0.0-1007.7`, NVIDIA `7.0.0-1013.13`, Raspberry Pi `7.0.0-1014.14`, OEM `7.0.0-1008.8`, Realtime `7.0.0-27.27.1`
24.04 mit HWE 6.17	AWS `6.17.0-1019.19~24.04.1`, Azure `6.17.0-1021.21~24.04.1`, GCP `6.17.0-1020.22~24.04.1`, Oracle `6.17.0-1018.18~24.04.1`, NVIDIA `6.17.0-1026.26`, OEM `6.17.0-1028.28`, Realtime `6.17.0-1017.19~24.04.1`

Die Ubuntu-Seite enthält weitere Cloud- und Spezialkernel. Der dort noch offene RISC-V-Source-Package-Status ist kein Beleg für eine technische RISC-V-Betroffenheit: ITScape sitzt ausschließlich im ARM64-KVM-Code.

Schnelle Prüfung auf ARM64-KVM-Hosts

Der erste Filter ist einfach:

uname -m
uname -r
lsmod | grep -E '^kvm[[:space:]]'

ls -l /dev/kvm
getent group kvm

aarch64 oder arm64, geladenes KVM und ein Kernel im betroffenen Vendor-Zweig sind ein Grund für die genauere Prüfung. Einen universellen Sysfs-Schalter „vITS aktiv“ gibt es nicht. Dafür muss die Maschinen- und VM-Konfiguration betrachtet werden.

Ein leerer lsmod-Treffer ist keine Entwarnung. KVM kann fest in den Kernel eingebaut sein (CONFIG_KVM=y). /dev/kvm, laufende QEMU-/Libvirt-Workloads und die Kernelkonfiguration müssen dann trotzdem geprüft werden.

# Libvirt-Definitionen nach ARM-GIC-/ITS-Hinweisen durchsuchen
virsh list --all 2>/dev/null
virsh dumpxml VM-NAME 2>/dev/null | grep -Ei 'aarch64|gic|its|machine'

# Laufende QEMU-Aufrufe als zusätzlicher Hinweis; fehlendes "its=on" ist kein Entwarnungsbeleg
ps -eo args | grep -E '[q]emu-system-aarch64.*(gic-version=3|its=on)' || true

Installierte Kernelpakete prüfen:

# Debian und Ubuntu
dpkg -l 'linux-image*' 2>/dev/null | awk '/^ii/ {print $2, $3}'

# RHEL, AlmaLinux, Rocky, Oracle, Fedora, SUSE: alle Kernelvarianten anzeigen
rpm -qa --qf '%{NAME} %{VERSION}-%{RELEASE}.%{ARCH}\n' 2>/dev/null \
  | awk '$1 ~ /^kernel($|-)/ {print}' \
  | sort

# Gentoo Distribution Kernel
qlist -Iv sys-kernel/gentoo-kernel sys-kernel/gentoo-kernel-bin 2>/dev/null || true

Nach jedem Update zählt wieder der laufende Kernel:

uname -r

Ein installierter Fixkernel schützt keine VM, solange der Host noch mit seinem Vorgänger läuft.

Mitigation und Updatepfad

ITScape hat keine so einfache, breit verfügbare Ausweichmaßnahme wie „Nested KVM abschalten“. Der betroffene ITS gehört zur normalen ARM64-Interruptvirtualisierung. Die belastbare Lösung ist deshalb ein gepatchter Host-Kernel.

Wo der Hersteller noch kein Update liefert, sollten Betreiber nicht vertrauenswürdige ARM64-VMs auf gepatchte Hosts migrieren. Alternativ müssen sie die VMs stoppen oder vorübergehend auf eine nicht betroffene Architektur beziehungsweise Plattform verschieben. Ob sich ein virtuelles ITS produktbezogen abschalten lässt, hängt von Hypervisor, Maschinenmodell und Gast ab; ohne Herstellerempfehlung ist das keine verlässliche Standard-Mitigation.

Livepatching zählt nur, wenn der Anbieter CVE-2026-46316 oder den konkreten Backport für den laufenden Kernel ausweist. Der Fix ändert die Referenzbehandlung in einem Race. Eine allgemeine Anzeige „alle Kernel-Patches aktuell“ ist kein ausreichender Nachweis.

Einordnung für ARM-Clouds und Proxmox

ARM64-KVM läuft bei Cloud-Anbietern, CI-Plattformen, selbst verwalteten Graviton-Instanzen und auf Ampere-Servern. Für Single-Tenant-Hosts ist ITScape planbar. Bei Multi-Tenant-Nodes ist Gast-root Teil des Produkts und damit keine wirksame Hürde.

Offizielles Proxmox VE gehört nicht zu diesen Plattformen. Die Hardwareanforderungen nennen Intel 64 oder AMD64, und die offiziellen Hostpakete werden für amd64 ausgeliefert. Ein emulierter ARM-Gast auf einem x86-Proxmox-Host erreicht den verwundbaren ARM64-KVM-Pfad ebenfalls nicht.

Community-Projekte, die PVE-ähnliche Stacks auf ARM portieren, sind davon nicht automatisch ausgenommen. Dort zählt der verwendete ARM64-Host-Kernel, nicht der Produktname.

Was beim Patchen gern übersehen wird

Nur die VM oder QEMU wird aktualisiert, obwohl der Fehler im Host-Kernel sitzt.
Ein ARM64-Cluster mischt Basiskernel, Cloud-Flavours und selbst gebaute Kernel.
Das Paket ist installiert, aber der Host wurde nicht in den Fixkernel gebootet.
Ein Vendor-Kernel wird allein wegen seiner älteren Versionsnummer als nicht betroffen eingestuft, obwohl KVM-Code zurückportiert wurde.
Ein Livepatch wird angenommen, ohne die konkrete CVE-Abdeckung zu prüfen.
Der Selftest wird auf einem produktiven Host ausgeführt. Er arbeitet absichtlich mit Kernel-Speicherkorruption.

Wie wir damit umgehen würden

Wir würden zuerst ARM64-KVM-Hosts mit nicht vertrauenswürdigen Gästen und mindestens zwei vCPUs erfassen. Danach kommen laufender Kernel, Vendor-Flavour und ITS-Konfiguration zusammen auf den Tisch. Diese Kombination ist belastbarer als ein pauschaler Versionsvergleich.

Gepatchte Nodes werden aktualisiert, sauber neu gestartet und mit uname -r dokumentiert. Für noch offene Zweige planen wir die Migration der VMs auf bereits abgesicherte Hosts. Nach der Wartung prüfen wir außerdem, ob alte Nodes oder abweichende Kernel-Slots wieder in den Scheduler geraten können.

Den öffentlichen ITScape-Selftest würden wir nicht auf einem Produktionsnode starten. Für die Priorisierung reichen Architektur, Host-Kernel, VM-Vertrauensmodell und Vendor-Advisory.

Update-Log

2026-06-01: ITScape wird mit PoC an security@kernel.org gemeldet; der Patch geht an die KVM/arm64-Mailingliste.
2026-06-05: Der Fix wird in den KVM-Tree und Mainline übernommen.
2026-06-09: CVE-2026-46316 wird vergeben.
2026-06-10: Embargo endet; oss-security-Hinweis, Write-up und Exploit werden veröffentlicht.
2026-08-07 02:42 Uhr CEST: Artikel erstellt. Upstream- und Vendor-Stände erneut geprüft, Demo lokal eingebunden.