KVM em ARM64: quem confirma o limite entre a VM e o host?

A condição publicada tem um alcance definido

Em comunicado de setembro de 2026, Hyunwoo Kim descreveu a CVE-2026-89775 como um escape entre convidado e host no KVM/ARM64 com virtualização aninhada habilitada. O pesquisador informou correção no kernel principal. O registro Ubuntu, consultado em 16 de outubro, distingue pacotes e versões. Essas fontes não demonstram exposição de toda VM Linux nem comprometimento de um provedor específico.

O inventário deve começar fora do convidado

Imagine um serviço de testes que permite a clientes criar ambientes virtuais. A equipe da aplicação conhece a imagem usada nas tarefas, mas outra equipe administra os hosts. Uma atualização dentro da VM pode atender a uma necessidade do convidado e ainda deixar sem resposta a pergunta sobre o componente que sustenta o isolamento.

Registre arquitetura, distribuição, pacote de kernel, instância em execução e responsável pelo host. Acrescente se a virtualização aninhada está disponível naquele serviço e como essa informação foi obtida. Uma capacidade do processador, uma opção oferecida pelo produto e uma configuração efetivamente habilitada precisam de registros próprios.

A responsabilidade precisa alcançar a camada certa

Quando a empresa administra o host, associe cada resposta a um ativo e a uma data. Quando o provedor administra essa camada, peça confirmação do produto e do serviço abrangidos, orientação aplicada e limitações da evidência fornecida. Uma declaração referente a outra família de instâncias não encerra a análise.

A análise sobre BTR e execução de código ajuda a localizar fronteiras, mas trata de outro mecanismo. Aqui, a questão é a condição de virtualização no host. Não use um teste de permissões da aplicação para afirmar que o isolamento entre máquinas resistiu à vulnerabilidade.

Defina evidências sem reproduzir um escape

Combine uma janela e um ambiente representativo com quem administra a plataforma. A proposta abaixo verifica inventário, implantação e operação; uma conclusão específica sobre resistência ao escape exigiria método e autorização próprios. Preserve essa limitação no relatório e na decisão de encerramento.

• Condição: identifique o host e o serviço, a configuração relevante e a fonte da confirmação, sem inferir o estado pelo sistema do convidado.
• Mudança: relacione a orientação aplicável à distribuição com a manutenção realizada e confira o kernel efetivamente em execução após o procedimento.
• Continuidade: execute uma carga legítima de teste, observe criação e encerramento das VMs e registre erros, resultados e responsáveis pela aceitação.
• Pendência: se a confirmação depender de terceiro, registre a pergunta enviada, a resposta recebida, o prazo e o motivo para qualquer exceção operacional.

Uma imagem corrigida precisa virar estado observado

Um catálogo pode oferecer uma imagem corrigida enquanto máquinas antigas continuam operando. Confira os hosts existentes e o processo que cria os próximos, respeitando a forma de manutenção suportada pelo produto. A revisão da biblioteca em execução apresenta a mesma disciplina de separar pacote disponível e componente carregado.

Reabra a decisão quando mudar a família de instâncias, o kernel, a capacidade oferecida aos usuários ou o fornecedor. Uma conclusão útil informa quais ativos foram avaliados, quais evidências sustentam a condição e o que continua fora do alcance observado. O resultado pertence à combinação examinada, com data e responsabilidade claras.

Perguntas frequentes

Leia também

• Código não confiável e limites de execução
• Correção disponível e componente em execução
• Da identificação do ativo ao aceite

Fontes e referências

• Hyunwoo Kim: divulgação KVM/ARM64 na oss-security
• Ubuntu: registro atualizado da CVE-2026-89775

Análise original da Pentesty, publicada em 16 de outubro de 2026. Os cenários propostos são orientações editoriais, com escopo e validação a definir para cada ambiente.