Este documento descreve a vulnerabilidade ITScape (CVE-2026-46316), relatada e corrigida por Hyunwoo Kim (@v4bel). Trata-se de uma vulnerabilidade de escape do KVM que permite que um convidado escape para o host em um ambiente KVM/arm64 e execute comandos no host com privilégio de kernel (root). Pelo que se sabe publicamente, este é o primeiro trabalho de pesquisa de exploit do tipo escape de convidado para host voltado ao KVM/arm64.
O ITScape explora uma condição de corrida na emulação do vGIC-ITS (Interrupt Translation Service) do KVM/arm64. Ele aciona a falha apenas com ações do lado do convidado para escapar para o host, podendo ameaçar o isolamento convidado-host de hosts KVM/arm64 que aceitam convidados não confiáveis, especialmente nuvens públicas arm64 multi-inquilino.
Diferentemente dos escapes de QEMU comumente publicados, a falha reside no KVM dentro do kernel, e não no espaço do usuário do QEMU. Portanto, ela funciona independentemente da emulação do QEMU e pode executar comandos no host com privilégio do kernel do host, em vez do privilégio de um processo de usuário (como o QEMU).
Para as informações técnicas detalhadas, veja aqui.
[!NOTE] Após o relato desta vulnerabilidade para [email protected], o embargo acordado foi encerrado, portanto, este documento do ITScape está agora publicado. Para a linha do tempo de divulgação, consulte o documento de detalhes técnicos.
Para testes seguros, é recomendável executar o PoC sob QEMU TCG. (O acionamento da vulnerabilidade não tem relação alguma com o QEMU.) Quando executado sob QEMU TCG, o PoC tem a seguinte estrutura.
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
Este PoC não é um exploit totalmente armado que roda imediatamente em um ambiente de nuvem arm64, mas sim um código de demonstração que reproduz a vulnerabilidade e a cadeia de exploit completa sobre um kvm selftest. Espera-se que um atacante que conheça a implementação da pilha de virtualização da nuvem alvo não ache difícil a weaponização em si, mas ela envolve portar a construção direta do lado do host do selftest para um caminho real orientado ao convidado e ajustar endereços, gadget, offsets, temporização da corrida e assim por diante para a versão e a configuração do kernel alvo. Um exploit real e armado existe, mas não está sendo divulgado.
# ./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
Este PoC tem a finalidade de fornecer informações precisas. Não o use em sistemas nos quais você não está autorizado a testar.
O ITScape (CVE-2026-46316) abrange o intervalo de 8201d1028caa (2024-04-25) a 13031fb6b835 (2026-06-05).
Se você opera um host KVM arm64 que aceita convidados multi-inquilino, ou usa uma instância em cima de um, verifique se o patch 13031fb6b835 está aplicado ao kernel do host (operadores diretamente, inquilinos por meio de seu provedor). Além disso, como esta é uma nova classe de vulnerabilidade, esperam-se mais variantes e vulnerabilidades subsequentes; portanto, fique atento. Dito isso, você precisará distinguir se uma vulnerabilidade subsequente é realmente acionável apenas por ações do convidado, sem ação do lado do host, e se ela é de fato explorável.
Não. A vulnerabilidade está em arch/arm64/kvm/vgic/. Se você não está em um host KVM arm64, não precisa se preocupar com esta vulnerabilidade.
Sim. Acionar o MMIO do GIC/ITS exige privilégio de kernel do convidado (EL1). Quando você recebe uma instância em uma nuvem pública, normalmente tem root na sua própria VM, então esse requisito é atendido. Em um cenário sem root no convidado, ele deve ser encadeado com um LPE, como o Dirty Frag.