Falha no KVM do Linux pode permitir escape de máquinas virtuais em hosts ARM64
Uma vulnerabilidade identificada no KVM, componente de virtualização integrado ao kernel Linux, pode permitir que uma máquina virtual leia ou altere áreas da memória do sistema hospedeiro. Registrado como CVE-2026-89775, o problema afeta uma configuração específica de virtualização aninhada em processadores ARM64 e pode levar ao escape da VM, com possibilidade de execução de código no host.
O defeito está relacionado ao suporte de virtualização aninhada do KVM para a arquitetura ARM64. Esse recurso permite que uma máquina virtual opere como hypervisor e crie outras máquinas virtuais dentro dela. Apesar de relevante para ambientes de testes, nuvens privadas e laboratórios, a função não é ativada por padrão em hosts ARM64 e depende de equipamentos Armv8.4 compatíveis com o recurso FEAT_NV2.
Por esse motivo, servidores ARM64 que nunca habilitaram a virtualização aninhada não se enquadram no cenário de ataque descrito. A superfície de exposição é, portanto, menor do que a de uma vulnerabilidade presente em qualquer instalação comum do KVM.
Como o problema acontece
A falha surge quando o sistema convidado organiza a memória de uma forma específica e um cálculo interno produz o valor zero. Nessa situação, uma operação que deveria invalidar entradas do TLB é ignorada.
O TLB, ou Translation Lookaside Buffer, é uma estrutura usada pelo processador para acelerar a tradução entre endereços virtuais e físicos. Quando uma página de memória deixa de ser válida, as referências correspondentes precisam ser removidas. Se isso não ocorre, uma página já liberada pode continuar mapeada e permanecer disponível com permissão de escrita.
O resultado é especialmente grave: a VM pode acessar uma página pertencente à memória do kernel do host em blocos de 64 bits. Esse acesso ocorre sem que uma interrupção de hardware devolva imediatamente o controle ao sistema hospedeiro. Segundo o pesquisador Hyunwoo Kim, responsável pela divulgação em 16 de setembro, essa condição pode ser transformada em um ataque de escape da máquina virtual e, posteriormente, em execução de código no host.
Risco de elevação de privilégios
Além do escape de uma VM já existente, há um segundo vetor de ataque. Em sistemas nos quais usuários comuns conseguem abrir o dispositivo `/dev/kvm`, um invasor local pode criar uma máquina virtual e tentar explorar a vulnerabilidade para obter privilégios de root.
Esse cenário também exige que a virtualização aninhada esteja habilitada. O Red Hat Enterprise Linux é citado como um caso relevante porque, em determinadas configurações, o `/dev/kvm` pode ser acessível por todos os usuários por padrão. A Red Hat considera o kernel do RHEL 10 afetado, enquanto as versões 6, 7, 8 e 9 não são classificadas como vulneráveis.
Administradores devem verificar não apenas a versão do kernel, mas também as permissões do dispositivo. A existência do KVM no sistema não significa, por si só, que o ataque seja possível; é necessário avaliar a combinação entre arquitetura ARM64, suporte ao recurso, virtualização aninhada e acesso ao dispositivo.
Versões potencialmente afetadas
Os registros do kernel indicam que o código associado ao problema está presente desde o Linux 6.16. Entretanto, a análise realizada durante a correção aponta que a condição efetivamente explorável teria surgido somente a partir do Linux 6.17. Assim, sistemas com a versão 6.16 podem conter trechos relacionados ao defeito, mas não necessariamente apresentam o comportamento necessário para o ataque.
No desenvolvimento upstream, a correção foi incorporada às versões 6.18.51, 7.2.5 e 7.3-rc1. A aplicação prática do patch depende, contudo, do ciclo de atualização adotado por cada distribuição.
O Ubuntu 26.04 é considerado vulnerável, inclusive em kernels utilizados por ambientes AWS, Azure e Google Cloud. Já o kernel padrão do Ubuntu 24.04 LTS não é afetado. Algumas versões mais recentes de hardware enablement, baseadas nos kernels 6.17 e 7.0, permanecem vulneráveis.
No Amazon Linux, a correção do pacote `kernel6.18` do AL2023 ainda estava pendente em 22 de setembro. Os demais kernels da distribuição não eram considerados afetados naquele momento. No Debian, as versões Bookworm e Trixie não possuem o código vulnerável. O Sid recebeu a correção na versão 7.2.6-1, enquanto o Forky continuava exposto.
Impacto em ambientes de nuvem
A possibilidade de escapar de uma máquina virtual gera preocupação em infraestruturas de computação em nuvem. Em um cenário extremo, um cliente poderia tentar alcançar recursos do host físico ou afetar outros tenants instalados na mesma máquina.
Apesar disso, o vetor específico da CVE-2026-89775 não está disponível em algumas ofertas ARM padrão dos principais provedores. A AWS informa suporte à virtualização aninhada em instâncias baseadas em Intel, enquanto o Google Cloud não oferece esse recurso em suas máquinas ARM. Essa limitação reduz o risco nesses ambientes, embora não elimine a necessidade de confirmar a configuração real de cada serviço.
Em nuvens privadas, datacenters próprios e plataformas de desenvolvimento, a situação pode ser diferente. Organizações que habilitam virtualização aninhada para testes de hypervisors, emulação de ambientes ou execução de cargas especiais devem tratar o caso com prioridade.
O que os administradores devem fazer
A primeira medida é identificar hosts ARM64 que utilizam KVM e verificar se a virtualização aninhada está ativa. Também é importante confirmar se usuários sem privilégios administrativos conseguem acessar `/dev/kvm`.
Quando possível, a recomendação é atualizar o kernel para uma versão que contenha a correção distribuída pelo fornecedor. Como as distribuições podem aplicar patches em versões próprias, a numeração do pacote nem sempre será igual à do kernel upstream. Por isso, o controle deve considerar os avisos e pacotes disponibilizados pela distribuição instalada.
Em servidores que não podem ser atualizados imediatamente, pode ser conveniente desativar a virtualização aninhada, restringir o acesso ao `/dev/kvm` e impedir que usuários não confiáveis criem máquinas virtuais. Essas medidas não substituem o patch, mas podem reduzir a exposição enquanto a atualização é preparada.
Também é recomendável revisar grupos de usuários, regras de udev, permissões de dispositivos e políticas de acesso ao hypervisor. Em ambientes multiusuário, o simples fato de permitir que qualquer conta local crie VMs pode ampliar consideravelmente o risco.
Severidade e exploração conhecida
As avaliações de severidade variam entre 7,8 e 9,3 em uma escala de dez pontos. Há concordância de que o impacto potencial é elevado e de que o atacante precisa ter acesso local, mas os fornecedores divergem sobre a complexidade da exploração.
O Ubuntu atribui pontuação CVSS 9,3 à vulnerabilidade, embora classifique a prioridade interna de correção como média. Até 22 de setembro, não havia código público de exploração nem evidências de ataques utilizando a CVE-2026-89775. O problema também não constava no catálogo Known Exploited Vulnerabilities da CISA, e a estimativa disponível apontava probabilidade inferior a 1% de exploração.
Mesmo sem ataques confirmados, falhas de escape de máquinas virtuais exigem atenção especial. A combinação de acesso à memória do kernel, possibilidade de execução de código e impacto em hosts compartilhados pode transformar uma exploração teórica em um incidente grave caso a configuração necessária esteja presente.
A CVE-2026-89775 é, portanto, um risco concentrado, mas de alto impacto. Empresas que não utilizam virtualização aninhada em ARM64 têm exposição significativamente menor. Já os administradores que dependem desse recurso devem revisar permissões, atualizar os kernels afetados e acompanhar os pacotes de segurança específicos de suas distribuições.