Uma falha no subsistema vhost do Linux permite que um usuário local leia e altere a memória do kernel, além de obter privilégios de administrador. O problema afeta versões do kernel lançadas ao longo de quase uma década. Em determinadas configurações de virtualização, uma máquina virtual não confiável também pode escrever na memória do sistema hospedeiro e assumir o controle do programa que a executa.
Identificada como
CVE-2026-74580
e batizada de Vghost, a falha foi descoberta pelo Tencent Zhuque Lab, que disponibilizou uma correção em 3 de agosto. Em 12 de outubro, o laboratório publicou uma análise detalhada, com demonstrações funcionais dos dois tipos de ataque. Até o momento, não há indícios públicos de que a vulnerabilidade tenha sido explorada.
O vhost é um componente do kernel Linux que acelera operações de rede e outras operações de entrada e saída de máquinas virtuais e contêineres. Um usuário local acessa esse componente por meio de um arquivo de dispositivo, geralmente /dev/vhost-net ou /dev/vhost-vsock.
No sistema hospedeiro, a falha permite que um usuário sem privilégios leia e altere qualquer endereço de memória do kernel, contorne o KASLR e obtenha privilégios de administrador. O ataque é determinístico: não exige preparação da memória nem depende de acertar o 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 com iommu_platform ativado, e o vhost opera no modo IOTLB do dispositivo, um sistema convidado não confiável pode acionar a mesma falha. Isso leva o kernel hospedeiro a gravar além dos limites da memória do processo QEMU, que executa a máquina virtual. A partir daí, o sistema convidado pode sobrescrever um ponteiro de função no QEMU e controlar o próximo trecho de código executado pelo processo hospedeiro, ou provocar sua interrupção.
Como funciona
O vhost mantém um pequeno cache dos mapeamentos de memória associados a cada anel virtual e às filas compartilhadas usadas para transferir dados. Quando encontra uma entrada no cache, o sistema considera que a região já foi verificada. O cache é limpo quando o mapeamento é atualizado ou invalidado, e também quando a fila é reiniciada. No entanto, isso não ocorre 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á ativa.
Com uma IOTLB de dispositivo associada, esses comandos aceitam os novos endereços sem verificá-los imediatamente, deixando a validação para uma etapa posterior. Depois que o cache é preenchido, essa verificação não chega a ocorrer, e o vhost continua traduzindo os novos endereços com base no mapeamento antigo. Em seguida, o kernel copia dados de ou para esse endereço sem conferir os limites. Assim, uma gravação no anel de elementos usados ou uma leitura de um descritor pode alcançar uma área fora da região mapeada. Isso dá ao invasor capacidade de leitura e gravação na memória do kernel.
A falha permaneceu no código por cerca de nove anos, após duas mudanças que, isoladamente, eram razoáveis. Uma alteração feita em 2017, no Linux 4.11, introduziu o cache e seu atalho. Outra, em 2020, no Linux 5.9, transferiu a verificação de endereços do comando para uma etapa posterior, removendo a validação que teria detectado o uso de um mapeamento desatualizado.
Quem é afetado e o que fazer
A falha afeta versões do kernel Linux da 4.11 à 7.2-rc4. O Tencent Zhuque Lab reproduziu toda a cadeia de ataque, de usuário local a administrador, 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 acesso ao arquivo de dispositivo era restrito ao grupo kvm. Nesse caso, o ataque exigia que o usuário já fizesse parte desse grupo.
Nas outras quatro imagens testadas, o arquivo de dispositivo podia ser lido por qualquer usuário, com permissões 0666.
A correção, registrada no commit de845981da67, limpa o cache sempre que o anel é reconfigurado. Instale um kernel que inclua a correção e reinicie o sistema. As primeiras versões estáveis do projeto principal com a correção são:
| Ramo estável | Primeira versão corrigida |
|---|---:|
| 5.10.y | 5.10.265 |
| 5.15.y | 5.15.216 |
| 6.1.y | 6.1.183 |
| 6.6.y | 6.6.152 |
| 6.12.y | 6.12.104 |
| 6.18.y | 6.18.45 |
| 7.1.y | 7.1.9 |
| 7.2 | 7.2 |
Os fornecedores podem incluir a correção em suas versões sem alterar o número de versão do kernel.
Red Hat, Amazon Linux e Oracle Linux já distribuíram correções. O Ubuntu corrigiu a versão 22.04. Em 13 de outubro, as versões de kernel do Ubuntu 24.04 e 26.04 ainda constavam como em processo de atualização.
Até instalar um kernel corrigido, restrinja o acesso aos arquivos de dispositivo do vhost. Remova as permissões de acesso 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 uso.
Não há uma medida temporária para impedir a fuga da máquina virtual para o sistema hospedeiro. Nesse cenário, a única solução é instalar um kernel corrigido.
Gravidade e descoberta com auxílio de IA
A falha recebeu classificação alta, mas não crítica, e as avaliações divergem sobre sua gravidade. A equipe de CVE do kernel.org atribuiu a ela a pontuação 8,8 e classificou o escopo como alterado. A avaliação considera que a gravação iniciada na máquina virtual alcança a memória do processo QEMU no sistema hospedeiro, atravessando a fronteira entre o sistema convidado e o hospedeiro.
A Red Hat atribuiu pontuação 7,3 e considerou que o escopo não foi alterado, por entender que o impacto permanece dentro do limite de confiança do próprio sistema hospedeiro. A empresa também avaliou como menor o impacto sobre a integridade. A Amazon atribuiu 7,8, enquanto a Oracle deu nota 7,3.
A falha foi encontrada com a ajuda do Corvus AI, um sistema multiagente desenvolvido pela Tencent para pesquisar vulnerabilidades no kernel. O registro da correção no projeto principal inclui um crédito de assistência ao sistema, e a Tencent afirma que sua plataforma identificou o problema.
Trata-se de pesquisa com auxílio de máquina, não de um ataque executado por IA. A mesma equipe e a mesma plataforma encontraram uma falha no kernel relacionada ao SCTP, que permaneceu por 18 anos no código e foi divulgada em agosto. Nos testes, ela também permitiu obter privilégios de administrador e escapar de um contêiner.
Publicidade
Vibecoding cria 10x mais sistemas, 20x mais vulneráveis. E quem ganha com isso é a galera do hacking ético e pentest. Quer ser pago para invadir sistemas? Então você tem que aprender com a Solyd que são os melhores do Brasil. Saiba mais...