Uma falha no subsistema vhost do kernel do Linux permite que um usuário local leia e escreva na memória do kernel à vontade e obtenha privilégios de root em quase uma década de versões do kernel. Em uma configuração de virtualização, ela permite que uma máquina virtual não confiável escreva na memória do host e assuma o controle do programa que executa a máquina virtual.
A vulnerabilidade é rastreada como CVE-2026-74580 (sigla de Common Vulnerabilities and Exposures, sistema internacional de catalogação de vulnerabilidades) e recebeu o nome de Vghost. A Tencent Zhuque Lab, equipe que encontrou a falha, liberou uma correção em 3 de agosto e publicou um relatório técnico completo em 12 de outubro, com demonstrações funcionais dos dois ataques. Não há nenhum sinal público de que a falha já tenha sido explorada.
vhost é a parte do kernel do Linux que acelera a rede e outras operações de entrada e saída (E/S) para máquinas virtuais e contêineres. Um usuário local acessa esse componente abrindo um nó de dispositivo, geralmente /dev/vhost-net ou /dev/vhost-vsock.
No host, a falha dá a um usuário sem privilégios uma forma confiável de ler e escrever em qualquer endereço do kernel, contornar o KASLR (sigla de Kernel Address Space Layout Randomization, mecanismo que randomiza os endereços de memória do kernel) e escalar privilégios até root. O ataque é determinístico: não exige preparação de memória nem depende de sorte no momento da execução.
O segundo ataque é mais restrito. Quando o dispositivo virtio de uma máquina virtual está atrás de uma IOMMU virtual (unidade de gerenciamento de memória de entrada e saída) com a opção iommu_platform ativada, e o vhost opera no modo device-IOTLB (cache de tradução de endereços de dispositivos), um convidado não confiável pode acionar o mesmo erro e fazer o kernel do host escrever além dos limites no processo QEMU do host. A partir daí, o convidado pode sobrescrever um ponteiro de função no QEMU (emulador de máquina virtual) e assumir o controle de para onde o processo do host seguirá em seguida, ou simplesmente derrubá-lo.
Como funciona
O vhost mantém um pequeno cache com os mapeamentos de memória por trás de cada anel virtual e das filas compartilhadas que usa para transferir dados. Um acerto no cache é tratado como prova de que a região já havia sido verificada. O cache é limpo quando o mapeamento é atualizado ou invalidado e quando a fila é reiniciada, mas não quando os comandos VHOST_SET_VRING_ADDR ou VHOST_SET_VRING_NUM alteram os endereços ou o tamanho do anel enquanto a fila está em uso.
Com um device IOTLB conectado, esses comandos aceitam os novos endereços sem verificá-los, deixando a checagem para depois. Uma vez que o cache está preenchido, a verificação posterior nunca é executada, e o vhost continua traduzindo novos endereços com o mapeamento antigo. O kernel então copia dados de e para esse ponteiro sem verificação de limites, de modo que uma escrita no used ring ou uma leitura de descritor atinge uma área fora da região mapeada. Isso dá ao atacante leitura e escrita no kernel.
A falha permaneceu no código por cerca de nove anos porque foram necessárias duas mudanças razoáveis para criá-la. Uma alteração de 2017 (Linux 4.11) acrescentou o cache e seu atalho. Uma alteração de 2020 (Linux 5.9) transferiu a verificação de endereços do comando para uma etapa posterior, removendo a checagem que, de outra forma, teria detectado a tradução desatualizada.
Quem é afetado e o que fazer
A falha afeta kernels do Linux da versão 4.11 até a 7.2-rc4. A Tencent reproduziu a cadeia completa, do usuário local até root, em cinco kernels de distribuições: Ubuntu 26.04, RHEL 9.8, Amazon Linux 2023, Microsoft Azure Linux 3.0 e Oracle Linux 10.2. No Ubuntu, o nó de dispositivo estava restrito ao grupo kvm, então o ponto de partida ali era um membro desse grupo, e não qualquer usuário.
Nas outras quatro imagens testadas, o nó tinha permissão 0666, ou seja, era legível por qualquer pessoa, e qualquer usuário local podia acessá-lo.
A correção (commit de845981da67) limpa o cache sempre que o anel é reconfigurado. Instale um kernel que contenha a correção e reinicie o sistema. As primeiras versões estáveis upstream corrigidas estão listadas abaixo; os fornecedores também podem aplicar a correção sem alterar o número de versão.
Red Hat, Amazon Linux e Oracle Linux já distribuíram correções. A Ubuntu corrigiu a versão 22.04 e, até 13 de outubro, ainda listava os kernels das versões 24.04 e 26.04 como em andamento.
Até que um kernel corrigido esteja instalado, restrinja o acesso aos nós de dispositivo do vhost. Remova o acesso de leitura para todos em /dev/vhost-net e /dev/vhost-vsock, limite o grupo proprietário a serviços de virtualização confiáveis e trate a participação nesse grupo como um privilégio enquanto o kernel vulnerável estiver em execução.
Não há solução provisória para a fuga do convidado para o host; nesse caminho, o kernel corrigido é a única solução.
A gravidade e o papel da IA na descoberta
A falha é classificada como alta, e não como crítica, mas os avaliadores discordam sobre o nível. A equipe de CVEs do kernel.org atribui nota 8.8 e marca o escopo como alterado, porque a escrita do convidado para o host atinge a memória do processo QEMU do host e ultrapassa a fronteira entre convidado e host.
A Red Hat atribui nota 7.3 e marca o escopo como não alterado, considerando que o impacto permanece dentro da fronteira de confiança do próprio host; além disso, classifica o impacto na integridade como menor. A Amazon atribuiu nota 7.8, e a Oracle, 7.3.
A falha foi encontrada com a ajuda do Corvus AI, um sistema multiagente desenvolvido pela Tencent para pesquisa de vulnerabilidades em kernels. A correção upstream credita o sistema em uma linha Assisted-by, e a Tencent afirma que o pipeline identificou a falha.
Trata-se de uma pesquisa assistida por máquina, e não de um ataque conduzido por IA. É a mesma equipe e o mesmo pipeline por trás de uma falha no SCTP (Stream Control Transmission Protocol, protocolo de transporte usado em redes), com 18 anos de existência, divulgada em agosto, que também chegou a root e, em testes, escapou de um contêiner.
