Como o VsockDrop alcança o nível de root sem hipervisor e sem privilégios

A versão resumida

Ir para a versão completa ↓

Uma vulnerabilidade no kernel do Linux, classificada com nota 5,5, agora tem um exploit público que transforma um usuário local sem privilégios no usuário root. Essa é a parte do VsockDrop (CVE-2026-53365) que merece atenção nesta semana.

O que é: O VsockDrop é uma exploração de escalonamento de privilégios locais (LPE) para o CVE-2026-53365, uma falha no caminho de envio zerocopy do virtio vsock do kernel do Linux. Quando um MSG_ZEROCOPY de grande porte envia fragmentos por vários buffers de soquete, apenas o último buffer contém o objeto de conclusão que o caminho de liberação procura. Todos os buffers anteriores a ele contêm páginas do usuário fixadas, e o kernel, então, descarta uma referência de página que nunca chegou a ser obtida.

Impacto potencial: Obter privilégios de root a partir de uma conta comum sem privilégios. A exploração reduz a contagem de referências de uma página a zero, faz com que essa página — ainda fixada — seja devolvida como cache de página para o /usr/bin/su, reescreve o caminho do interpretador armazenado nela e executa o su. Não há vazamento de informações nem execução de código do kernel em nenhum ponto da cadeia, o que explica em grande parte por que ela funciona de maneira tão consistente.

Gravidade: Tanto a Red Hat quanto o NVD publicam uma pontuação CVSS base de 5,5 para o CVE-2026-53365, com alto impacto na disponibilidade e sem impacto na confidencialidade ou integridade; a Red Hat classifica a vulnerabilidade como “Moderada”. O autor da exploração defende uma pontuação de 7,8. O vetor descreve a falha na contabilidade de recursos documentada na mensagem de commit do upstream. Ele não leva em conta a interação com o io_uring que transforma o mesmo objeto de conclusão ausente em uma página liberada enquanto ainda está em uso. Seja qual for o resultado final da pontuação, a exploração pública demonstra consequências para a confidencialidade e a integridade que o vetor de 5,5 publicado atualmente não captura.

Quem está vulnerável: O Ubuntu merece a atenção mais imediata. Os kernels do Linux a partir da versão 6.7 que não receberam a correção estão afetados, e a viabilidade do ataque depende de um processo sem privilégios ser capaz de usar buffers registrados pelo io_uring em conjunto com um transporte vsock que permita zerocopy. Ambos estão disponíveis por padrão no Ubuntu 24.04 e no Ubuntu 22.04 executando o kernel 6.8 HWE. O Enterprise Linux 9 e 10, incluindo RHEL, AlmaLinux, Rocky e CloudLinux, contêm o mesmo código vulnerável, mas são fornecidos com a variável `kernel.io_uring_disabled` definida como 2, o que bloqueia a cadeia de exploração demonstrada.

O que foi verificado: Em 18 de agosto de 2026, a TuxCare conseguiu reproduzir um shell de root no Ubuntu 24.04 a partir de uma conta sem privilégios logo na primeira tentativa, sem nenhuma alteração na configuração. No AlmaLinux 10.2, a mesma exploração parou na inicialização do io_uring, conforme fornecido, e, em seguida, concedeu acesso root assim que o io_uring foi explicitamente reativado. Uma tentativa no AlmaLinux 9.8 com o io_uring reativado não conseguiu acesso root, o que não equivale a um resultado negativo definitivo.

O que fazer agora: Identifique o kernel em execução e a política do io_uring e, em seguida, verifique se o vsock está carregado.

uname -r
sysctl kernel.io_uring_disabled
lsmod | grep -E 'vsock|vmw_vsock'

Um valor igual a 2 significa que o io_uring é negado em todo o sistema, inclusive para o usuário root, o que bloqueia a rota de exploração conhecida do root sem remover o código vulnerável. Um valor igual a 0 significa que o io_uring está disponível, o que é o padrão do desenvolvedor original e o que o Ubuntu fornece. A saída do terceiro comando confirma que um módulo relacionado ao vsock está carregado. A exploração pública pode usar o vsock_loopback e o VMADDR_CID_LOCAL, portanto, não é necessária uma máquina virtual.

Aplique um kernel de fornecedor fixo, caso exista. O Debian 13 possui um. A Canonical ainda não disponibilizou um para as duas versões do Ubuntu mais importantes. Nos casos em que não é possível reiniciar o sistema imediatamente, o KernelCare é a solução mais comum para obter um kernel em funcionamento que não apresente mais o bug; e, como ainda não foi lançado nenhum patch que não exija reinicialização para este CVE, as medidas de mitigação abaixo são as únicas disponíveis para esses sistemas por enquanto.

O mais interessante sobre o VsockDrop não é o fato de existir mais um CVE relacionado ao kernel do Linux. É a diferença entre o que o registro do CVE descreve e o que a exploração divulgada ao público realmente faz.

A vulnerabilidade CVE-2026-53365 foi publicada em 13 de julho de 2026, dois meses após a correção do projeto original já ter sido implementada em 14 de maio. A descrição oficial aborda o rastreamento da conclusão do zerocopy e páginas fixadas que nunca são liberadas; tanto a Red Hat quanto o NVD atribuem a essa vulnerabilidade uma pontuação de 5,5, com impacto restrito à disponibilidade.

Então, a vulnerabilidade divulgada publicamente mudou o panorama prático. Ela demonstrou que a mesma falha de contagem de referências, combinada com buffers registrados com io_uring, libera uma página que ainda está fixada, a recupera como parte de um binário setuid e transforma um usuário local comum no root.

Uma falha, duas consequências. O CVE registrou a menos grave delas. Se uma nota 5,5 em um relatório de vulnerabilidade foi o motivo pelo qual isso foi retirado da lista de correções, ela deve ser incluída novamente.

O que é o CVE-2026-53365, também conhecido como VsockDrop?

O VsockDrop é um exploit de escalonamento de privilégios local sem privilégios para a vulnerabilidade CVE-2026-53365 no kernel do Linux, publicado em agosto de 2026 por Maher Azzouzi, que é creditado como o autor da denúncia na correção do upstream. O nome se refere ao exploit e ao artigo explicativo, e não a uma vulnerabilidade específica.

O código vulnerável está localizado no caminho de envio zerocopy do virtio vsock. O AF_VSOCK geralmente está associado à comunicação entre um sistema convidado e seu hipervisor; portanto, a suposição natural é que se trate de um problema de virtualização. Mas não é. O Linux expõe um ID de contexto vsock local por meio do transporte vsock_loopback, VMADDR_CID_LOCAL, que corresponde ao CID 1, e a prova de conceito usa esse ponto de extremidade para se comunicar de volta com o mesmo sistema. Nenhum hipervisor, nenhum sistema convidado, nenhum namespace de usuário e nenhuma verificação de capacidade se interpõem entre uma conta comum e o código vulnerável.

Portanto, o pré-requisito não é o controle de um hipervisor. É a capacidade de executar um binário como um usuário local comum em um kernel afetado, no qual os recursos necessários estejam disponíveis. Em hospedagem compartilhada, sistemas de compilação multilocatários, executores de CI e hosts de transição, isso descreve a maioria das contas na máquina.

A segunda peça fundamental é o io_uring. A exploração utiliza buffers registrados em conjunto com o envio por zerocopy, e é essa interação específica que transforma um bug de contagem de páginas em um underflow de referência e, posteriormente, em privilégios de root.

O momento também é importante. A correção está disponível ao público desde 14 de maio de 2026, de autoria de Stefano Garzarella, da Red Hat, e a exploração surgiu cerca de três meses depois. Ninguém foi pego de surpresa, o que também significa que todos os kernels sem patch já estavam expostos a uma correção publicada há um trimestre inteiro.

Como funciona a vulnerabilidade de root do VsockDrop

Um envio MSG_ZEROCOPY não copia a carga útil. O kernel bloqueia as páginas do usuário, transmite a partir delas e, posteriormente, notifica o espaço do usuário por meio da fila de erros quando essas páginas podem ser reutilizadas com segurança. O objeto que controla tudo isso é o ubuf_info, geralmente chamado de uarg.

No modo zerocopy, o caminho de envio do vsock limita cada buffer de socket a 64 KiB; portanto, qualquer coisa maior é fragmentada. Antes da correção, o uarg era anexado apenas ao buffer final do ciclo. Os buffers anteriores ainda continham páginas fixadas, sem nenhum dos estados de conclusão que o kernel esperava encontrar ali.

Por si só, isso gera o problema de contabilidade de recursos descrito pelo CVE. O espaço do usuário nunca é informado de que essas páginas estão livres e, se o ciclo de envio for interrompido prematuramente, o uarg nunca chega a ser alocado.

Com buffers registrados por io_uring, as consequências são diferentes. Essas páginas já estão fixadas a longo prazo, e a pilha de rede marca os fragmentos como referências gerenciadas, o que significa que o caminho de liberação deve ignorá-las. A proteção que garante isso está inserida em uma verificação para saber se o buffer possui um uarg associado. A ausência de uarg faz com que a verificação falhe, a proteção nunca seja consultada e o loop unref chame put_page() nos fragmentos que nunca receberam uma referência. O resultado é um decréscimento indesejado na contagem de referências de página a cada envio.

O envio da mesma carga útil por meio de um iovec comum não gera nada disso. Nesse caso, o io_uring obtém as referências corretas, os saldos de contabilidade ficam equilibrados e resta apenas o vazamento de memória. Sem io_uring, não há underflow.

A partir daí, a matemática não é favorável. O pin bias é 1024, uma constante fixa do ABI; portanto, um número conhecido de envios esgota uma quantidade conhecida da contagem de referência em qualquer kernel afetado. Registre um buffer, desmapeie-o, envie até que a contagem chegue a zero, e o kernel libera uma página na qual o io_uring ainda mantém um pin. Ao ler uma página fria de /usr/bin/su, o alocador devolve essa mesma página física diretamente como cache de página, pois a lista de páginas livres segue o princípio “último a entrar, primeiro a sair” (LIFO). O buffer ainda registrado agora aponta para esse cache de página; uma gravação fixa reescreve o caminho do interpretador ELF, e a execução do su faz com que o kernel carregue um interpretador fornecido pelo invasor com credenciais de root já aplicadas.

Não há execução de código do kernel nessa cadeia. Trata-se de um caminho exclusivamente de dados até o usuário root, e se o padrão parecer familiar, é porque de fato é. A vulnerabilidade “Copy Fail” (CVE-2026-31431) utilizou uma ideia semelhante no início de 2026, corrompendo o cache de páginas de um binário setuid para alcançar o usuário root sem modificar o arquivo subjacente. A vulnerabilidade “VsockDrop” chega a um alvo semelhante por meio de uma falha no kernel bem diferente.

Há um detalhe importante para quem estiver testando isso. O dreno de referência é determinístico. A etapa de recuperação de páginas é probabilística, e uma tentativa malsucedida não pode ser repetida na mesma inicialização. Portanto, a exploração é confiável sem ser de uso único, e uma única execução malsucedida não é prova de que um kernel não seja afetado.

Já foi confirmado que o VsockDrop pode ser explorado?

Sim, em um kernel do Ubuntu 24.04 afetado, sem alterações na configuração.

A TuxCare reproduziu a vulnerabilidade divulgada publicamente no Ubuntu 24.04 em 18 de agosto de 2026, executando um kernel Azure 6.17. A execução foi iniciada a partir de uma conta sem privilégios e gerou um shell de root na primeira tentativa, sem que nada tivesse sido ajustado ou reconfigurado. O único efeito colateral foi uma entrada “BUG: Bad page state” no dmesg. Essa imagem não contém a correção, e a Canonical ainda não lançou uma correção para ela.

O AlmaLinux 10.2 se comportou de maneira bem diferente. A exploração falhou imediatamente com a mensagem “io_uring init failed”, o que indica que a configuração padrão do kernel, `io_uring_disabled = 2`, está funcionando exatamente como deveria. O SELinux não é o que a impede, caso essa seja a suposição que está no ar. Não houve recusas do AVC, e a execução ainda falhou com o SELinux no modo permissivo. Com o sysctl definido como 0, a tentativa seguinte concedeu privilégios de root, com um dmesg limpo e sem erros (oops).

“Mitigado na forma como foi entregue” não é o mesmo que “corrigido”.

O AlmaLinux 9.8 é o caso que merece atenção especial. Com o io_uring reativado, a exploração foi executada do início ao fim e, em seguida, falhou sem conceder privilégios de root. Isso não é um resultado negativo definitivo. Todas as pré-condições de código para o underflow estão presentes no kernel 5.14 fornecido, o opcode de envio zerocopy necessário para a exploração foi portado para essa linha de kernel, e a Red Hat ainda marca o RHEL 9 como afetado. A assinatura da falha correspondeu a uma falha conhecida em um host que já havia sido invadido. O Enterprise Linux 9 deve ser tratado como afetado no código até que um teste adequado indique o contrário.

Uma execução malsucedida também deixa rastros, o que é mais útil do que parece. A exploração só limpa seus rastros em caso de sucesso; portanto, uma tentativa malsucedida deixa para trás os arquivos /tmp/loader e /var/tmp/.s, sendo que /var/tmp/.s está com o atributo setuid root. Trata-se de um vetor de escalonamento de privilégios local deixado no host por uma tentativa que nem sequer funcionou, e ninguém costuma procurar em /var/tmp. Remova-o manualmente.

Uma execução bem-sucedida interrompe o `su` até a reinicialização, com a mensagem “Não é possível executar: arquivo necessário não encontrado”. Limpar os caches não ajuda, pois a página corrompida ainda mantém uma referência; portanto, somente uma reinicialização a restaura. Esse é um sinal de detecção simples e, por si só, uma interrupção visível ao usuário. A corrupção permanece no cache de páginas e, no AlmaLinux, o comando `rpm -V util-linux-core` retornou sem erros posteriormente, indicando que o binário no disco estava intacto. Em um sistema de arquivos do tipo “copy-on-write”, isso pode não se sustentar, conforme o próprio aviso do autor da exploração.

O Ubuntu 24.04 está vulnerável ao VsockDrop?

Sim. As versões do kernel do Ubuntu 24.04 afetadas estão vulneráveis, e a exploração pública de privilégios de root foi reproduzida no Ubuntu 24.04 sem nenhuma alteração na configuração.

Atualmente, a Canonical classifica o CVE-2026-53365 como vulnerável nos pacotes do kernel Noble, abrangendo as linhas 6.8 GA e 6.17 HWE, juntamente com as variantes AWS, Azure, GCP e GKE. O Ubuntu 22.04, que roda o kernel 6.8 HWE, também é classificado como vulnerável, e essa é a base de instalação maior entre as duas.

O Ubuntu é mais importante do que a lista de pacotes afetados sugere, pois sua configuração padrão do io_uring deixa o pré-requisito para a exploração vulnerável disponível. A Canonical também classifica o CVE como de risco médio, e é por isso que não foi necessário emitir nenhum aviso de segurança para essas linhas.

Os kernels mais recentes baseados na versão 7.0 estão sendo desenvolvidos separadamente. Atualmente, a Canonical lista tanto o Ubuntu 26.04 quanto a linha Ubuntu 24.04 HWE 7.0 como vulneráveis, com correções em andamento; portanto, verifique o status exato do pacote antes de presumir que qualquer um deles já tenha sido corrigido.

Quais sistemas Linux são afetados?

Apenas o panorama geral é simples. O trabalho com o vsock MSG_ZEROCOPY, que introduziu esse comportamento, foi incorporado ao Linux 6.7, e as correções estáveis estão nas versões 6.12.97, 6.18.34, 7.0.11 e 7.1. Os kernels das distribuições devem ser avaliados por meio de avisos e pacotes, pois os fornecedores fazem o backport de recursos constantemente. O RHEL 9 informa um kernel baseado na versão 5.14, numericamente mais antigo que o 6.7, e a Red Hat ainda indica que o RHEL 9 e o RHEL 10 estão afetados, sem que nenhuma correção tenha sido fornecida, pois o recurso foi retroportado para essa linha de kernel.

Os backports transferem tanto os recursos vulneráveis quanto as correções para números de versão que não correspondem aos do upstream; portanto, considere o comando `uname -r` como um identificador a ser consultado, e não como um veredicto.

O que protege o Enterprise Linux 9 e 10 é essa configuração padrão, e não um patch; além disso, ela é compilada no kernel, em vez de ser fornecida como um arquivo sysctl. Assim, qualquer sistema que inicialize com esse kernel a herda, a menos que o espaço do usuário a altere posteriormente. Cargas de trabalho de bancos de dados, proxies e contêineres alteram essa configuração deliberadamente — o que torna a vulnerabilidade nesses hosts real, e não hipotética.

Como mitigar o VsockDrop

A sequência demonstrada requer buffers registrados com io_uring e um transporte vsock que permita zerocopy. A remoção de qualquer um desses pré-requisitos faz com que ela deixe de funcionar, o que é uma situação melhor do que a que a maioria dos bugs do kernel deixa você. Nenhum desses controles substitui a correção no kernel.

1. Mantenha o io_uring desativado. No Enterprise Linux 9 e 10, o valor 2 já é a configuração padrão; portanto, trata-se de uma etapa de verificação, e não de uma alteração. Evite alterá-lo, a menos que uma carga de trabalho realmente exija o io_uring.

O Ubuntu é o caso oposto. Desativar o io_uring nesse sistema remove funcionalidades das quais os aplicativos em execução podem depender, incluindo bancos de dados, proxies e softwares de armazenamento de alta taxa de transferência; portanto, trate isso como uma mudança operacional real com um impacto significativo. É também a única opção de tempo de execução disponível para esses sistemas até que uma correção seja disponibilizada. Quando um serviço específico precisa do io_uring, um valor de 1 combinado com kernel.io_uring_group permite seu uso apenas para membros desse grupo, e qualquer valor diferente de 2 não deve ser interpretado como equivalente à desativação total.

2. Remova o transporte vsock onde ele não for necessário. Em um servidor físico sem usuários do vsock, colocar o módulo na lista negra geralmente ocorre sem problemas.

lsmod | grep -E 'vsock|vmw_vsock'

Não aplique isso cegamente a uma máquina que, por sua vez, seja um convidado. Tanto o agente convidado do QEMU quanto o VMware Tools utilizam transportes vsock, assim como a virtualização aninhada e qualquer solução do tipo Firecracker. Módulos já carregados precisam ser removidos com o comando `rmmod` ou requerem uma reinicialização para que a lista negra tenha efeito; portanto, confirme se o módulo foi realmente removido depois disso.

Nenhuma dessas medidas de controle foi testada contra essa vulnerabilidade específica; portanto, considere-as como medidas para eliminar os pré-requisitos, e não como uma neutralização comprovada.

A correção do VsockDrop

A correção no upstream é o commit ae38d9179190, “vsock/virtio: correção da conclusão do zerocopy para envios com múltiplos SKBs”, e segue o que o TCP já faz.

Em vez de criar o uarg no meio do ciclo de envio e anexá-lo ao último buffer disponível, a correção o aloca antecipadamente, anexa-o a cada buffer por meio de uma referência específica para cada um e, posteriormente, equilibra a referência inicial. Cada conclusão decrementa a contagem; a notificação é disparada somente quando o último buffer é liberado; e um envio que falha sem transmitir nada encerra o uarg de forma limpa.

Isso resolve ambas as consequências de uma só vez. Agora, cada buffer contém um uarg, de modo que o mecanismo de proteção de fragmentos gerenciados no caminho de liberação é consultado da maneira como sempre deveria ter sido, e as quedas de referências perdidas deixam de ocorrer. O trabalho de retroportação varia de acordo com o grau de divergência de cada kernel de fornecedor em relação à linha principal.

A correção está presente nas versões estáveis do upstream 6.12.97, 6.18.34, 7.0.11 e 7.1. Os kernels de fornecedores podem incluir a mesma correção sob números de versão totalmente diferentes.

Status da correção sem reinicialização para CVE-2026-53365

Até o dia 18 de agosto de 2026, a equipe do KernelCare está trabalhando em patches dinâmicos que não exigem reinicialização para a maioria das distribuições afetadas. Espera-se que os primeiros patches sejam implantados em até 48 horas.

Quando as atualizações são lançadas, elas chegam na próxima execução programada ou sob demanda.

kcarectl --update

Em seguida, verifique o que o kernel em execução está realmente carregando.

kcarectl --patch-info | grep 'CVE-2026-53365'

Caso a consulta não retorne nenhum resultado, não interprete essa ausência como cobertura ou como uma lacuna. Confirme o kernel exato junto ao suporte antes de remover uma mitigação temporária, e não depois. O carimbo de data e hora da compilação de um patch é um sinal secundário menos confiável e não deve ser tratado como prova para qualquer CVE específico.

Saiba como o KernelCare corrige vulnerabilidades críticas do kernel sem a necessidade de reinicialização → 

Perguntas frequentes sobre o VsockDrop

O que um invasor precisa para explorar a vulnerabilidade CVE-2026-53365? A capacidade de executar um binário como um usuário local sem privilégios em um kernel afetado, com o io_uring disponível e um transporte vsock carregável. Sem hipervisor, sem sistema convidado, sem namespace de usuário e sem hardware especial.

O VsockDrop requer uma máquina virtual? Não, e essa é a parte em que a maioria dos resumos se confunde. O transporte vsock_loopback permite que um processo sem privilégios se comunique consigo mesmo por meio do CID local; portanto, um host “bare-metal”, sem qualquer tipo de virtualização, ainda está dentro das possibilidades.

O RHEL 9 e o RHEL 10 são afetados pela vulnerabilidade VsockDrop? A Red Hat classifica ambos como afetados, incluindo o kernel-rt, sem que nenhuma correção tenha sido disponibilizada. A exploração pública não funciona da forma como foi divulgada, pois esses kernels bloqueiam o io_uring por padrão; portanto, a vulnerabilidade só se manifesta quando essa configuração padrão é alterada.

A vulnerabilidade CVE-2026-53365 pode ser explorada remotamente? Não. É necessária uma conta local. Isso ainda abrange hospedagem compartilhada, sistemas de compilação multilocatários, executores de CI e qualquer host em que um usuário do aplicativo possa executar um binário.

Como saber se alguém já tentou isso? Verifique se existe /var/tmp/.s — que uma tentativa malsucedida deixa para trás como um binário setuid root — e se existe /tmp/loader. Um comando `su` com falha, informando que falta um arquivo necessário, juntamente com a mensagem “BUG: Bad page state” no `dmesg`, indica que a execução foi bem-sucedida nessa inicialização.

Existe algum patch para o CVE-2026-53365? As correções do upstream estão nas versões 6.12.97, 6.18.34, 7.0.11 e 7.1, e o Debian já disponibilizou correções para o trixie e para o kernel bookworm 6.12. A Canonical ainda não disponibilizou nenhuma correção para as versões afetadas do Ubuntu, e, até o momento da redação deste artigo, nenhum patch que não exija reinicialização foi lançado para este CVE.

Cronograma do VsockDrop

Referências

• Maher Azzouzi, prova de conceito e relatório técnico do VsockDrop, https://github.com/MaherAzzouzi/vsockdrop
• Correção do upstream do Linux ae38d9179190, “vsock/virtio: correção da conclusão do zerocopy para envios com múltiplos SKBs”, https://git.kernel.org/linus/ae38d9179190a956e2a87a69ef1dd6f451b51c4d
• Commit 581512a6dc93, “vsock/virtio: suporte ao sinalizador MSG_ZEROCOPY”, que introduziu o código afetado no Linux 6.7
• Commit 1cb36e252211, a correção relacionada à contabilidade de páginas fixadas, cuja revisão revelou esse defeito
• Red Hat CVE-2026-53365, https://access.redhat.com/security/cve/cve-2026-53365
• NVD CVE-2026-53365, https://nvd.nist.gov/vuln/detail/CVE-2026-53365
• Ubuntu CVE-2026-53365, https://ubuntu.com/security/CVE-2026-53365
• Debian CVE-2026-53365, https://security-tracker.debian.org/tracker/CVE-2026-53365