Januscape: a vulnerabilidade de KVM que poderia desencadear execução de código no host de uma VM com root

Um erro de tipo use- aafter-free no hipervisor KVM do Linux, batizado como Januscape e rastreado como CVE-2026-53359, permite que um convidado (guest) com privilégios root dentro da máquina virtual corrompa as estruturas internas de paginação que o KVM mantém no kernel do anfitrião (host). A demonstração pública causa um pânico do kernel do host; o pesquisador que o descobriu, Hyunwoo Kim (@v4bel), afirma ainda que existe um exploit não publicado que converte a mesma corrupção em execução de código no host, algo que elevaria o impacto de uma simples queda a uma fuga completa de confinamento entre inquilinos de uma máquina física.

A raiz do problema está no código da chamada "shadow MMU" — uma camada que KVM usa para manter suas próprias tabelas de páginas que refletem o espaço de endereços do convidado — e não é específico da Intel ou AMD: a mesma lógica vulnerável foi compartilhada e ativava o bug em ambos os ecossistemas. Durante anos KVM reutilizava páginas de rastreamento apenas comprobando o endereço físico (gfn), sem verificar o papel Essa página estava desempenhando. Como consequência, KVM às vezes entregava uma página do tipo errado, o que misturava seus registros internos e provocava corrupção; a resposta típica do kernel é abortar imediatamente para evitar danos maiores, mas se a página liberada se reastribua antes da limpeza, o posterior acesso pode sobrepor memória que já não pertence ao kernel, oferecendo ao atacante controle sobre onde se escreve, e desde essa limitada primazia muitas técnicas permitem escalar até controle de execução.

É importante ressaltar dois fatos operacionais que aumentam o risco real: primeiro, a falha existe desde o código inicial de 2010 (commit 2032a93d66fa) e permaneceu inadvertido cerca de 16 anos; segundo, o vetor de exploração relevante em ambientes multiusuário exige que o convidado tenha root dentro da VM e que o host tenha exposto a virtualização aninhada (nested virtualization). Embora muitos hosts usem o EPT/NPT por hardware, a exposição de ested força a KVM volta à rota legada de shadow MMU, que é exatamente onde vive o Januscape.

A correcção upstream é mínima mas eficaz: uma verificação adicional no kvm_mmu_get_child_sp () que obriga a que além do número de moldura (gfn) o papel.word Corresponde antes de reutilizar uma página de shadow, evitando assim misturar tipos diferentes. O adesivo foi integrado em 19 de junho de 2026; você pode consultar o commit na árvore principal do kernel aqui: commit 81ccda30b4e8. As versões estáveis com backport público foram publicadas em 4 de julho de 2026 (incluindo 7.1.3, 6.18.38, 6.12.95, 6.6.144, 6.1.177, 5.15.211 e 5.10.260).

Da perspectiva de defesa, a primeira ação imediata para qualquer operador de hosts x86 que aceite convidados não confiáveis é avaliar e aplicar adesivos; não espere a uma pontuação CVSS na NVD para reagir. Verifique se a sua distribuição forneceu a correção através do changelog do pacote do kernel (as distribuições geralmente backportem correções sob números de versão próprios), e verifique a presença do commit de referência ou do número de adesivos nas notas do pacote. Para inspecionar se a virtualização aninhada está ativa em um host pode usar estes nodos do sistema: /sys/module/kvm_intel/parameters/nested ou /sys/module/kvm_amd/parameters/nested; uma leitura diferente de 0 indica que a capacidade está activa.

Se você não puder colocar um adesivo imediatamente, veja o vetor mais direto desativando a virtualização aninhada com a opção de módulo correspondente (por exemplo, kvm_ intel.nested=0 ou kvm_ amd.nested=0), seja como parâmetro de arranque do kernel ou através da configuração do módulo na sua distribuição. Lembre- se que você pode baixar o módulo kvm_intel/kvm_amd em um host que executa máquinas virtuais pode não ser viável sem um reinício planejado; por isso a mitigação por configuração do GRUB e reboot controlado é normalmente a estratégia operacional mais segura e reprodutível.

Os provedores de nuvem e os administradores de ambientes multi-tenant devem elevar a prioridade deste arranjo: um único inquilino com acesso root a uma VM que também tenha ested habilitado pode forçar um pânico do host e derrubar todas as VMs coabitadas, e segundo o pesquisador pode até alcançar a execução de código com privilégios de kernel se o exploit completo estiver disponível. Revise também permissões locais em sistemas que hospedam KVM: em algumas distribuições (/dev/kvm com modo 0666, por exemplo), a interface exponível pode facilitar escalagens locais além da rota guest-to-host.

Para operadores que queiram verificar rapidamente: confirme o que o kernel está a correr, verifique o changelog do pacote do seu fornecedor (não confiar apenas em umame - r), verifique a configuração de ested em /sys/module/.../parameters/nested e, se apropriado, planifique um reinício com a opção kvm_* .nested=0 na linha de arranque até que o adesivo esteja instalado. Documentação técnica sobre o KVM e virtualização no Linux pode ser consultado no manual do kernel: Documentação do KVM no kernel.org. Para contexto sobre o descubridor e como foi relatado o achado, o perfil público do pesquisador pode ser consultado: perfil de Hyunwoo Kim.

Januscape faz parte de uma série de descobertas recentes em KVM: nos últimos meses o mesmo pesquisador publicou outros exploits e foram corrigidas falhas relacionadas na rota de shadow MMU, sugerindo que essa porção legada do código merece auditoria adicional. Conclusão prática: trate qualquer host x86 que aceite convidados não confiáveis e tenha ested habilitado como prioridade alta de adesivo; aplique a correção ou, entretanto, desactive ested e coordene comunicados e ações com seus inquilinos e fornecedores de nuvem para minimizar impacto e restaurar confiança.