O que é o Zapscape e como proteger hosts KVM

A versão resumida

Ir para a versão completa ↓

O que é: CVE-2026-64561, batizada de Zapscape por seu descobridor, Hyunwoo Kim (@v4bel), é uma vulnerabilidade do tipo “use-after-free” na unidade de gerenciamento de memória sombra x86 do KVM do Linux. Dois caminhos de falha de página validam a raiz da memória sombra antes de recuperar as páginas da memória sombra, em vez de depois; assim, o KVM continua criando mapeamentos abaixo de uma raiz que já foi invalidada pela recuperação. O resultado é uma fuga completa do ambiente convidado para o host. O PoC publicado documenta um caminho para executar código como root no host, e não apenas um panic que encerra todas as VMs co-locadas. Ir para esta seção →

Impacto potencial: O pesquisador relata um caminho que leva da execução de código no kernel do host a partir de uma máquina virtual convidada controlada pelo invasor, o que representaria uma fuga completa da máquina virtual para o host. A mesma divulgação descreve dois outros resultados: um “panic” no host que interrompe todas as cargas de trabalho em execução na máquina afetada e um caminho separado de escalonamento de privilégios locais que se inicia a partir de uma conta comum no host, onde /dev/kvm é gravável por todos. Ir para esta seção →

Gravidade: A Red Hat classifica a vulnerabilidade como “Importante”, com uma pontuação base CVSS 3.1 de 7,0 sob o código CWE-825. A exploração requer privilégios do kernel do convidado, virtualização aninhada e uma configuração compatível do host. A própria descrição da Red Hat define o impacto como instabilidade e negação de serviço em ambientes virtualizados, o que é uma interpretação significativamente mais branda do que a do pesquisador. Ir para esta seção →

Quem está em risco: Hosts que executam o KVM com a virtualização aninhada ativada, em um kernel que contém a alteração introduzida pelo commit f95eec9bed76 no Linux 5.9 e ainda não contém a correção do upstream 2abd5287f083. Os sistemas AMD SVM que utilizam tabelas de páginas aninhadas são os mais facilmente acessíveis. Os sistemas Intel exigem que tanto as percursos de páginas EPT de quatro níveis quanto os de cinco níveis sejam expostos ao convidado de primeiro nível, o que limita essa opção aos processadores Ice Lake-SP e mais recentes. Ir para esta seção →

O que foi comprovado: A prova de conceito pública não resultou em uma fuga do convidado para o host em kernels compilados com o CloudLinux em nossos testes. Ela não funciona nesses kernels sem modificações, e a reprodução interna resultou, até o momento, apenas em uma falha do convidado de primeiro nível. Considere a fuga como plausível, mas não como um comprometimento comprovado em toda a frota. Ir para esta seção →

O que fazer agora: Comece verificando se um host está, de fato, incluído no escopo.

cat /sys/module/kvm_amd/parameters/nested 2>/dev/null
cat /sys/module/kvm_intel/parameters/nested 2>/dev/null

A 1 ou Y significa que o módulo KVM carregado permite a virtualização aninhada, o que coloca o host dentro da superfície de ataque potencial. Isso, por si só, não comprova a possibilidade de exploração, já que o estado dos patches do kernel, os recursos da CPU do host, o modelo da CPU virtual exposta ao L1 e o fato de um convidado não confiável poder criar um L2 ainda são fatores importantes.

A ausência de saída geralmente significa que o módulo KVM correspondente não está carregado no momento, o que não é o mesmo que estar fora do escopo; portanto, verifique como o host é realmente utilizado e se o KVM pode ser carregado posteriormente. Leia o arquivo em vez de presumir que ninguém ativou o aninhamento, pois o KVM upstream habilitou o parâmetro de aninhamento por padrão tanto para Intel quanto para AMD desde o Linux 4.20, e uma distribuição pode substituir esse padrão em qualquer sentido.

Em hosts que não precisam de virtualização aninhada, desative-a, pois isso remove o pré-requisito do qual toda a cadeia depende. Verifique /dev/kvm permissões como uma medida de fortalecimento à parte, já que você está trabalhando nisso.

O KernelCare corrige essa falha no kernel em execução sem a necessidade de reinicialização do sistema ou da máquina virtual. Os primeiros patches que não exigem reinicialização já foram lançados: o Debian 13 está no repositório principal, e o Ubuntu 24.04, o Ubuntu 24.04 para AWS, o Ubuntu 22.04 para AWS com kernels 6.8 e o Proxmox VE 8 têm compilações no repositório de teste, com previsão de serem promovidas para o repositório principal. As demais famílias ainda estão em fase de compilação e revisão, com a disponibilidade sendo disponibilizada por kernel e repositório à medida que a validação for concluída. Aplique um kernel corrigido pelo fabricante, caso já exista um para sua plataforma.

Há duas descrições do Zapscape em circulação, e elas são muito diferentes uma da outra. O pesquisador descreve uma cadeia que culmina na execução de código do kernel do host a partir de dentro de um guest. A Red Hat descreve instabilidade em ambientes virtualizados. Ambos estão se referindo ao mesmo commit.

A resposta honesta está entre as duas, e os detalhes a seguir explicam o motivo. O que foi reproduzido internamente é mais restrito do que a divulgação sugere. A prova de conceito pública pode causar a falha do convidado L1 controlado pelo invasor em alguns ambientes, enquanto o pesquisador documenta um caminho — que depende da configuração — para a execução de código no host. Vale a pena deixar essa diferença bem clara, e nenhuma das duas interpretações constitui um argumento para deixar uma barreira de virtualização comprometida sem correção.

A virtualização aninhada permite que uma máquina virtual execute suas próprias máquinas virtuais. Um cliente de nuvem pode utilizá-la para executar um hipervisor, testar software de infraestrutura, operar um ambiente de CI ou habilitar recursos do Windows que dependem do Hyper-V.

Isso resulta em uma estrutura de três níveis:

• L0 é o host físico
• L1 é o sistema convidado controlado pelo invasor
• L2 é uma máquina virtual criada dentro de L1

O Zapscape explora falhas no gerenciamento de memória que o L0 realiza ao atender às atividades do L2. O invasor começa com privilégios de root no L1 e cria a máquina virtual aninhada necessária para acionar o caminho vulnerável do KVM.

Ter acesso root dentro de uma máquina virtual na nuvem não é incomum. Os clientes normalmente controlam seus próprios sistemas operacionais convidados, e a barreira de segurança tem como objetivo impedir que esse acesso chegue ao hipervisor. O Zapscape tem como alvo a própria barreira de segurança.

O KVM utiliza tabelas de páginas sombra para converter os acessos à memória do convidado em mapeamentos do host e libera essas estruturas assim que atinge sua cota de páginas ativas da MMU.

Os caminhos de falha vulneráveis, direct_page_fault() e FNAME(page_fault)(), chamado is_page_fault_stale() antes make_mmu_pages_available().

Essa ordem é o problema.

Recuperação interna make_mmu_pages_available() pode eliminar a raiz que o KVM está usando no momento e marcá-la como inválida. Como a verificação de raiz obsoleta já foi executada, o KVM continua criando mapeamentos sob uma raiz que não é mais válida. As páginas-sombra filhas herdam a função de suas páginas-mãe; portanto, elas herdam o estado inválido, e as páginas inválidas acabam voltando para a lista de páginas ativas da MMU.

Esse é o commit invariante f95eec9bed76 adicionado no Linux 5.9 para evitar isso. Se ocorrer uma falha, uma limpeza recursiva posterior por meio de mmu_page_zap_pte() funciona sem root_count protege e atua em estruturas que já foram liberadas.

A prova de conceito conduz a sequência ao alternar os modos de memória dentro da L1 para criar páginas-sombra de alias, enquanto a atividade de memória da L2 leva a L0 a um processo de recuperação baseado em cota. O pesquisador, então, aproveita a corrupção resultante para executar código do kernel do host.

O problema de ordenação em si remonta a 2008. Ele passou a ter relevância para a segurança no Linux 5.9, quando a invariante que ele viola foi introduzida. Ninguém relatou um bug na versão 5.9. O kernel simplesmente passou a depender de algo que nunca havia sido verdade.

O pesquisador apresenta uma prova de conceito do lado do convidado e documenta um caminho completo para a execução de código no host. A explorabilidade, no entanto, depende fortemente da configuração. A vulnerabilidade tem como alvo a AMD e foi desenvolvida para uma configuração específica do Linux 7.1.3 no QEMU TCG, e não em hardware de produção; portanto, para atingir um host real, seria necessário reescrever as ações do lado do convidado e adaptá-las à configuração do kernel de destino.

Nossos testes não conseguiram reproduzir a fuga completa em nenhum kernel compilado com o CloudLinux. A exploração divulgada publicamente não funciona nesses kernels sem modificações, e o resultado observado é uma falha no convidado L1, o que representa uma negação de serviço para a própria máquina virtual do invasor, e não um comprometimento do host.

O Enterprise Linux 8 merece uma observação para quem estiver testando por conta própria. A prova de conceito pública não causa absolutamente nada nesse sistema, nem mesmo uma falha, portanto não pode servir como referência de comparação “antes e depois” para essa família. Valide os kernels do EL8 com um conjunto de testes geral do KVM, em vez de tirar conclusões com base na ausência de erros.

Nada disso prova que os kernels afetados sejam seguros. Isso significa que a vulnerabilidade deve ser descrita com precisão. O Zapscape apresenta um caminho de fuga do convidado para o anfitrião que parece plausível, e a exploração divulgada publicamente não é, no momento, uma fuga universal para todos os kernels que contêm o código vulnerável.

O caminho de código vulnerável existe desde a alteração no Linux 5.9, no commit f95eec9bed76, datado de 8 de julho de 2020, por meio de kernels que não receberam a correção 2abd5287f083, que pousou a montante em 21 de julho de 2026.

A acessibilidade exige, além disso:

• KVM em uso
• Virtualização aninhada a ser ativada
• Controle no nível do kernel dentro do convidado L1
• Recursos da CPU do host e da CPU virtual compatíveis com o ataque

Em hosts AMD que utilizam SVM e tabelas de páginas aninhadas, a divulgação não identifica nenhum pré-requisito adicional de recurso da CPU além dos principais requisitos já listados. Os sistemas Intel só são compatíveis quando os comprimentos de percurso de página EPT de quatro e cinco níveis estão expostos à L1, o que geralmente significa Ice Lake-SP e versões mais recentes com esses recursos habilitados.

Famílias de plataformas afetadas ou potencialmente afetadas identificadas durante nossa análise:

• Enterprise Linux 10, AlmaLinux 10 e CloudLinux 10, onde o backport do CentOS Stream 10 ainda está em fase de rascunho
• Kernels mais antigos do Enterprise Linux 8 e 9 que não contêm a correção do fornecedor, incluindo versões derivadas do EL8
• Debian 11, 12 e 13
• Ubuntu 22.04 e 24.04
• Oracle UEK7
• Proxmox VE 7 e VE 8

Já corrigido ou fora do escopo:

• Kernels do RHEL 8 a partir de 4.18.0-553.147.1.el8_10 a partir de, enviado em 23 de julho de 2026
• Kernels do RHEL 9 a partir de 5.14.0-687.30.1.el9_8 a partir de, enviado em 22 de julho de 2026
• RHEL 6 e RHEL 7, incluindo o kernel-rt, que são anteriores à alteração no Linux 5.9 que tornou a falha relevante para a segurança
• Qualquer host que não esteja executando o KVM ou que o esteja executando com a virtualização aninhada desativada

As entradas do RHEL têm uma pegadinha. A Red Hat lançou a correção discretamente, agrupada com outras correções de vulnerabilidades, e sua página pública do CVE continuou listando o RHEL 8 e o RHEL 9 como afetados mesmo após a publicação dessas errata. As evidências do changelog são o indicador mais confiável, e sabe-se que o status da página pode mudar em questão de horas; portanto, verifique novamente os dados atuais da Red Hat antes de informar a um cliente ou auditor que o sistema está afetado.

A mesma precaução se aplica de maneira mais geral. Os kernels dos fornecedores incorporam alterações individuais constantemente, portanto, o número da versão do upstream não é um indicador do nível de vulnerabilidade. Verifique o comunicado e o status do patch para o kernel específico que está em execução.

Como mitigar o Zapscape

Todos os pré-requisitos para esse bug são elementos que podem ser removidos. Todos os três são medidas temporárias, não substitutos para a correção.

1. Desative a virtualização aninhada. Essa é a opção mais direta, pois a cadeia exige que o L1 crie e opere sua própria máquina virtual.

# /etc/modprobe.d/99-zapscape.conf
options kvm_amd nested=0
options kvm_intel nested=0

O parâmetro do módulo é lido no momento do carregamento; portanto, aplicá-lo significa interromper todas as máquinas virtuais em execução e recarregá-las kvm_amd ou kvm_intel. Em um servidor de produção, isso representa uma sobrecarga ou a necessidade de reinicialização, em vez de uma alteração em tempo real.

Se a frota executar máquinas virtuais comuns de nível único, aplique a atualização e siga em frente, já que nada nessa carga de trabalho requer virtualização aninhada. Se o host oferecer essa funcionalidade deliberadamente — considere locatários de hipervisores aninhados, sistemas de CI que inicializam máquinas virtuais, ambientes virtualizados de desenvolvimento e teste ou máquinas convidadas do Windows que utilizam VBS ou Hyper-V —, mantenha-a ativada e priorize a aplicação de patches. Avalie o impacto na carga de trabalho antes de mexer em um host que você não tenha configurado.

2. Restringir o acesso a /dev/kvm. Isso não resolve o problema de um ataque proveniente de um convidado já existente. Isso bloqueia o caminho separado pelo qual um usuário local comum no host acessa o KVM diretamente.

ls -l /dev/kvm

Se o dispositivo exibir o modo 0666, bloqueie-o e conceda acesso aos usuários legítimos por meio do kvm grupo. Faça essa alteração em uma regra do udev, em vez de usar um simples chmod, já que o udev redefine o modo na próxima inicialização ou ao ocorrer um evento no dispositivo.

3. Analise a exposição ao EPT em cinco níveis na Intel. Isso só é relevante quando ambos os recursos do EPT atingem o nível L1.

grep -w ept_5level /proc/cpuinfo

A ausência de saída significa que o host não possui a capacidade de EPT de cinco níveis necessária para o caminho da Intel descrito. Se o sinalizador estiver presente, a próxima questão é se tanto o EPT de quatro níveis quanto o de cinco níveis estão de fato chegando ao convidado L1 não confiável, uma vez que /proc/cpuinfo descreve a CPU do host, e não o que o modelo de CPU virtual transmite. Quando a virtualização aninhada precisar permanecer ativada, evite modelos de CPU que exponham o EPT de cinco níveis a convidados não confiáveis. Em sistemas Intel mais recentes, desativar a virtualização aninhada ainda é a medida temporária mais confiável.

Assim que a proteção estiver ativada, remova a configuração temporária com sudo rm /etc/modprobe.d/99-zapscape.conf e recarregar o módulo durante a próxima janela de manutenção.

A Solução

A correção no upstream foi confirmada 2abd5287f083, “KVM: x86: Verificar se há uma raiz inválida ou obsoleta após disponibilizar as páginas da MMU.”

A alteração é pequena. Ela transfere a verificação de “stale-root” para depois de make_mmu_pages_available() em ambos os caminhos de falha afetados, em menos de uma dúzia de linhas alteradas ao longo de arch/x86/kvm/mmu/mmu.c e arch/x86/kvm/mmu/paging_tmpl.h. Agora, o KVM realiza primeiro qualquer recuperação e, em seguida, confirma se a raiz ainda é válida antes de prosseguir, o que impede que o hipervisor crie mapeamentos ativos sob uma raiz que já tenha sido invalidada pela recuperação.

Sem nenhuma nova estrutura de dados, sem estado persistente para monitorar. É isso que a torna adequada para a aplicação de patches sem reinicialização, embora o próprio backport varie de acordo com o quanto as rotas de falha do kernel de cada fornecedor se afastaram da linha principal.

Status e implantação de patches do KernelCare

A partir de 11 de agosto de 2026, as primeiras versões já estão disponíveis:

Debian 13: repositório principal
Ubuntu 24.04 Noble, Ubuntu 24.04 Noble para AWS, Ubuntu 22.04 Jammy para AWS, kernels 6.8 e Proxmox VE 8 estão no repositório de testes

Esperava-se que as compilações do feed de teste chegassem ao feed principal ainda no mesmo dia; portanto, verifique o status do feed do seu kernel, em vez de presumir que elas ainda estejam apenas na fase de teste.

Situação familiar atual:

Todos os kernels do Enterprise Linux 9 estão abrangidos por patches em revisão, com exceção dos kernels mais antigos da série 70, que precisam de adaptação e foram transferidos para um trabalho separado

• Os patches do Ubuntu 24.04 estão prontos e em revisão
• Os patches do Debian 12 estão em revisão e aguardam validação de hardware
• Foram preparadas correções para o Enterprise Linux 8 e o Ubuntu 22.04, cuja validação ainda está pendente
• O Enterprise Linux 10 está na fila

O hardware de teste da AMD, e não a complexidade dos patches, tem sido o fator limitante em várias famílias. A disponibilidade variará de acordo com o kernel até a conclusão dos testes e da implantação.

Se você estiver ansioso para atualizar enquanto um patch ainda estiver no canal de testes:

kcarectl --update --prefix test

Após a implantação no canal de produção, a correção é aplicada na próxima execução programada ou sob demanda:

kcarectl --update

Em seguida, verifique o que está realmente carregado no kernel em execução:

kcarectl --patch-info | grep 'CVE-2026-64561'

A data e hora da compilação constituem a verificação secundária:

kcarectl --info | grep kpatch-build-time

Uma compilação com data de 6 de agosto de 2026 ou posterior é um indicador útil, mas não uma garantia de que esse CVE específico esteja coberto por esse kernel. Caso as informações do patch ainda não mencionem o CVE, confirme a cobertura para o kernel específico por meio do suporte ao cliente, em vez de considerar a data como prova. De qualquer forma, verifique antes de remover uma mitigação temporária, e não depois.

Saiba como o KernelCare corrige vulnerabilidades críticas do kernel sem a necessidade de reinicialização →

Linha do tempo

Referências

• Hyunwoo Kim (@v4bel), divulgação do Zapscape ao oss-security
• Documento técnico e prova de conceito do Zapscape, zapscape.io
• Correção no código-fonte do Linux 2abd5287f083, “KVM: x86: Verificar se há uma raiz inválida ou obsoleta após disponibilizar as páginas da MMU”
• Commit no Linux f95eec9bed76, “KVM: x86/mmu: Não recolocar SPs inválidos na lista de páginas ativas”
• Aviso da Red Hat e registro CVE para CVE-2026-64561
• Solicitação de fusão 3068 para o backport do CentOS Stream 10, em rascunho
• Alertas aplicáveis ao RHEL, AlmaLinux, CloudLinux, Debian, Ubuntu, Oracle e Proxmox