Zapscape: a vulnerabilidade de KVM que poderia escapar da VM e tomar o controle do host

Zapscape é a etiqueta que recebeu uma vulnerabilidade crítica detectada no subsistema KVM do kernel Linux que gerencia a MMU “shadow” para a tradução de memória em ambientes de virtualização aninhada. O erro, rastreio como CVE-2026-64561, permite que um atacante que já tenha privilégios de kernel dentro de uma máquina virtual L1 (ou seja, normalmente root nessa VM) escape do isolamento do KVM e execute código com privilégios do host. Embora o vetor exija um contexto de privilégios elevados dentro do L1 e condições concretas na CPU, o potencial impacto em ambientes que expõem a virtualização a convidados não confiáveis é significativo: um convidado malicioso poderia comprometer o host e, por extensão, outras VMs e cargas de trabalho sobre esse host.

Tecnicamente, a vulnerabilidade é um problema de ordem na verificação de raízes obsoletas (stale-root) dentro do bookkeeping da shadow-MMU que pode produzir um use-after-free. Durante o manejo de uma page fault provocada pelo convidado, KVM pode reclamar páginas de MMU e invalidar a raiz de shadow-MMU que ainda está sendo usada no caminho de manejo da falta. Como a rota não volta a verificar essa raiz, KVM pode continuar a criar páginas filhas sob uma raiz invalidada, o que leva finalmente a ligações suspensas e escrituras posteriores à libertação. O pesquisador Hyunwoo Kim publicou uma demonstração técnica e um proof-of-concept público que mostra como, a partir deste primitivo, é possível executar uma cadeia completa de exploração capaz de criar um arquivo no host (p. ex. /Zapscape) com propriedade do root do host.

Há condições concretas para que o ataque seja exploravel: além do requisito habitual de privilégios de kernel dentro de L1, em sistemas Intel é necessário expor ao convidado L1 o comprimento de page-walk de EPT tanto 4 como 5; AMD não exige essa condição adicional e o PoC público de Kim é dirigido a SVM/NPT em AMD sobre Linux 7.1.3. É importante sublinhar que QEMU não é o componente vulnerável: a falha vive no código in-kernel de KVM e pode ser desencadeada independentemente do emulador; Kim até recomenda usar QEMU TCG para testes seguros do PoC porque QEMU em si não é a superfície explorável.

O panorama de adesivos já é claro: o arranjo upstream foi fusionado (commit 2abd5287f083) e move a verificação de stale-root para depois de make_mmu_pages_available (), fazendo com que, se a reclamação invalida a raiz atual, KVM reinicie a falha com RET_PF_RETRY em vez de continuar em uma raiz inválida. A NVD lista kernels a partir de 5.9 em diante como afetados até as versões estáveis sistemaadas; entre as versões com o arranjo upstream são mencionadas 6.6.148, 6.12.101, 6.18.42 e 7.1.6. Os administradores também devem rever os avisos de suas distribuições porque muitos distribuidores (por exemplo, Red Hat) aplicam adesivos em forma de backports dentro de pacotes com numerações diferentes da de upstream. Você pode consultar o seguimento oficial na NVD e o commit no repositório do kernel: NVD — CVE-2026-64561 e commit 2abd5287f083 em git.kernel.org.

Quanto ao risco real e mitigação operacional: Kim esclarece que o PoC não é “armamento pronto para a nuvem” imediato; um exploit em produção exigiria portar ações L1 a um módulo de kernel no convidado e adaptar a exploração à configuração do kernel do host e ao seu backend de memória. No entanto, a existência de um teste público obriga a agir rapidamente. Red Hat emitiu uma qualificação preliminar CVSS 7.0 e classificou o problema como CWE-825 (expired pointer dereference), o que sublinha a severidade e a possibilidade de escalada ao controle do host.

Se você administra infra-estruturas baseadas em KVM e especialmente se você expõe ested virtualization ou fornece VMs “com capacidade de aninhar” a clientes ou usuários, as acções imediatas recomendadas são: aplicar os adesivos oficiais ou pacotes do seu distribuidor que incluam a correção, ou se não for possível corrigir imediatamente, desactivar a exposição de virtualização aninhada a convidados não confiáveis. Além disso, adicione que convidados têm privilégios de kernel (root) ou acesso a hardware que permita ativar condições de exploração, e minimiza a partilha de capacidades de virtualização em ambientes multiinquilino. Verifique os trackers de segurança da sua distribuição porque o estado e o número de versão podem variar se o fornecedor tiver backportedo o fix.

Para equipamentos de resposta e pesquisa interna que desejem reproduzir ou analisar o problema, o PoC público de Kim está disponível com sua análise técnica; usar o QEMU TCG para testes reduz o risco de danos acidentais ao não depender de aceleração por hardware. Não utilize testes do PoC em ambientes de produção ou em hosts compartilhados sem isolamento estrito. Os links do pesquisador e do aviso upstream permitem compreender a técnica e verificar o adesivo aplicado na árvore oficial do kernel.

Zapscape é, em contexto, parte de uma série de descobertas recentes em KVM que incluem falhas anteriores como Januscape (CVE-2026-53359) e ITScape (CVE-2026-46316), o que evidencia que a complexidade do código de shadow-MMU e a virtualização aninhada continuam sendo uma superfície crítica. A lição operacional é priorizar adesivos de kernel em hosts de virtualização, reduzir a exposição de características avançadas a convidados não confiáveis e manter políticas rigorosas de privilégios dentro das VMs. Para confirmações e guias de remediação específicas à sua distribuição, consulta também as páginas de segurança do seu fornecedor e as notas de lançamento: por exemplo, as páginas da Rede Hat sobre CVE e os repositórios de kernel das suas distribuições.

Fontes e referências para seguir a resposta: o registro oficial do CVE na NVD, o commit do kernel com o patch e as páginas de segurança de distribuidores como Red Hat. Veja estes recursos para verificar que seus hosts estão em versões adesivos ou que seus pacotes incluem o backport correspondente antes de considerar um ambiente seguro contra CVE-2026-64561.