La trilogia dell'escape KVM

ITScape (CVE‑2026‑46316)

Januscape (CVE‑2026‑53359)

Zapscape (CVE‑2026‑64561)

Zapscape: Escape da guest a host in KVM/x86

Sommario

Questo documento descrive la vulnerabilità Zapscape (CVE-2026-64561) scoperta e segnalata da Hyunwoo Kim (@v4bel). Si tratta di una vulnerabilità di escape di KVM che consente a una guest di evadere verso l'host in un ambiente KVM/x86 e di eseguire comandi sull'host con privilegi di kernel (root).

Zapscape è una vulnerabilità use-after-free nell'emulazione della shadow MMU di KVM/x86, in particolare nel percorso zap ricorsivo che viene eseguito quando le shadow page vengono recuperate. Può innescare il bug con sole azioni lato guest per corrompere la shadow page del kernel dell'host e può minacciare l'isolamento guest-host degli host KVM/x86 che accettano guest non fidati ed espongono la virtualizzazione annidata, in particolare i cloud pubblici x86 multi-tenant.

Per le informazioni tecniche dettagliate, vedi qui.

[!NOTE] Dopo aver segnalato questa vulnerabilità a [email protected], l'embargo concordato è terminato, quindi l'exploit è stato pubblicato su oss-security e questo documento Zapscape è stato reso pubblico. Per la timeline di divulgazione, consulta il documento dei dettagli tecnici.

Struttura del PoC

Il PoC è scritto per colpire AMD e, per un test sicuro, si consiglia di eseguirlo sotto QEMU TCG. Il PoC ha la seguente struttura.

L0: Linux 7.1.3 + KVM_AMD on an x86_64 CPU (AMD SVM/NPT) emulated by QEMU TCG. The escape target
  └─ L1: the guest poc creates. Switching long -> PAE aliases one shadow page as both child and pinned root, and L1 then escalates the UAF into L0 kernel code-exec
       └─ L2: the guest L1 VMRUNs. Its memory touches trigger L0's quota reclaim -> recursive zap with no root_count guard -> UAF

Questo PoC non è un exploit weaponizzato che viene eseguito immediatamente in un ambiente cloud, ma un codice dimostrativo che riproduce la vulnerabilità e l'intera catena di exploit su QEMU TCG. Per usarlo in un ambiente cloud reale, le azioni L1 eseguite dal PoC devono essere spostate in un modulo del kernel della guest e l'exploit deve essere adattato al kconfig del kernel host. Non è un compito difficile.

Utilizzo del PoC

1. Scarica il sorgente del kernel vulnerabile v7.1.3, quindi compila l'immagine del kernel basata sul kconfig incluso.
2. Compila il PoC, quindi componi un initramfs adatto usando BusyBox o simile e inserisci il PoC compilato nell'initramfs.

# gcc -O2 -g -static -pthread poc.c -o poc

3. Avvia il target Linux 7.1.3 con il seguente comando. Testa su QEMU v9.2.0 o successivo.

# ./qemu.sh bzImage initramfs.cpio.gz

4. Dopo l'avvio di QEMU TCG, esegui il PoC. In caso di exploit riuscito, evade dalla guest e crea il file /Zapscape di proprietà di root sull'host.

 /$$$$$$$$  /$$$$$$  /$$$$$$$
|_____ $$  /$$__  $$| $$__  $$
     /$$/ | $$  \ $$| $$  \ $$
    /$$/  | $$$$$$$$| $$$$$$$/
   /$$/   | $$__  $$| $$____/
  /$$/    | $$  | $$| $$
 /$$$$$$$$| $$  | $$| $$
|________/|__/  |__/|__/

[+] /Zapscape created by the target KVM host kernel (owner uid=0, mode=0644).
[+] exploit completed - verify with: ls -la /Zapscape
zapscape(uid=65534)$ ls -la /Zapscape
-rw-r--r--    1 root     root             0 Jul 29 05:27 /Zapscape
zapscape(uid=65534)$

Questo PoC ha lo scopo di fornire informazioni accurate. Non usarlo su sistemi che non sei autorizzato a testare.

Versioni interessate

Zapscape (CVE-2026-64561) copre l'intervallo da f95eec9bed76 (2020-07-08) a 2abd5287f083 (2026-07-21).

FAQ

Qual è l'impatto di questa vulnerabilità?

Lo stesso di Januscape (CVE-2026-53359):

1. Escape KVM: con sole azioni lato guest, un attaccante può compromettere l'host che esegue la propria VM. Ad esempio, un attaccante che ha affittato una sola istanza su un cloud pubblico potrebbe mandare in panic il kernel dell'host per far cadere tutte le altre VM tenant sulla stessa macchina fisica (DoS), oppure eseguire codice con privilegi di root sull'host per impossessarsi dell'host e di tutti i guest su di esso (RCE).
2. LPE: su distribuzioni come RHEL, /dev/kvm è scrivibile da tutti (0666), quindi un utente non privilegiato può usare questa vulnerabilità anche come LPE per ottenere root. Quando viene usata come LPE, gli ioctl VMM lato host sono disponibili, quindi l'exploit diventa più semplice e stabile.

Come è collegata a Januscape?

Si verifica nella stessa shadow MMU, ma è una vulnerabilità separata con una causa principale diversa.

Detto questo, a differenza di Januscape, su Intel può essere innescata solo quando sia la lunghezza 4 che la 5 del page walk EPT sono esposte a L1. Questo è un punto importante quando si valuta l'ambito interessato, quindi deve essere compreso con precisione. Vedi il documento dei dettagli tecnici.

Questa vulnerabilità si verifica in QEMU?

No. Come Januscape, si verifica nel KVM in-kernel, quindi viene innescata indipendentemente dall'emulazione di QEMU. Per questo può minacciare anche i grandi cloud pubblici che implementano e usano il proprio stack di virtualizzazione.

È necessario avere root all'interno della VM guest?

Sì. È richiesto il privilegio di root nel kernel L1. Quando ti viene allocata un'istanza su un cloud pubblico, di solito hai root sulla tua VM, quindi il requisito è soddisfatto. In uno scenario senza root nella guest, deve essere concatenata con un LPE come Dirty Frag.

Pensi che le vulnerabilità di KVM continueranno a emergere?

Sì. Consiglio di stabilire un processo di patch sostenibile per gli hypervisor host. L'inverno sta arrivando.

Hai in programma un sequel dopo la trilogia?

Spero di no.