O PwnEscape ficou oculto na pilha de rede do kernel por 18 anos

A versão resumida

O que é: CVE-2026-99999, que o pesquisador denomina PwnEscape, é uma falha na forma como o kernel do Linux calcula as somas de verificação IPv4 para pacotes que chegam com metadados de offload anexados. Uma máquina virtual convidada pode fornecer metadados de offload de soma de verificação que fazem com que o host grave dois bytes em um cabeçalho IPv4 que o kernel já havia validado. O CNA do kernel publicou a vulnerabilidade em 15 de outubro de 2026.

Impacto: A memória do host vaza nos pacotes enviados pelo guest, e a Vercel afirma que essa vulnerabilidade foi demonstrada em suas sandboxes de produção. O pesquisador também causou falhas nos hosts e executou código neles como root, mas apenas em suas próprias máquinas KVM e Firecracker, configuradas para corresponder à infraestrutura da Vercel.

Gravidade: O kernel CNA classifica a vulnerabilidade como 9,3 (Crítica) segundo o CVSS 3.1, com um vetor de ataque local e um escopo alterado. Em um host multilocatário, porém, “local” pode significar uma VM alugada por um de seus clientes, e o dano recai sobre o host subjacente a ela.

Quem é afetado: O código vulnerável remonta ao Linux 2.6.27, de 2008. Espera-se que os kernels do Enterprise Linux, do EL7 ao EL10, sejam afetados, incluindo RHEL, AlmaLinux, Rocky Linux, Oracle Linux e CloudLinux, embora as árvores de código-fonte individuais ainda não tenham sido verificadas. Os hosts que executam máquinas virtuais sobre as quais não têm controle são os primeiros a serem afetados, juntamente com servidores compartilhados nos quais usuários não confiáveis possuem acesso a um shell. Nas versões EL8 a EL10, o diretório /dev/kvm é gravável por todos por padrão; portanto, esses usuários podem ser capazes de inicializar uma máquina virtual própria e atacar o host a partir dela.

Status: A correção foi incorporada ao código principal em 14 de outubro, e sete kernels estáveis do upstream foram lançados com ela em 15 de outubro. Até 16 de outubro, nenhum kernel de distribuição havia lançado a correção. Não há código de exploração público nem relatos de exploração em ambiente real. Trata-se de uma divulgação coordenada, não de um zero-day.

Faça isso agora: nos hosts que executam máquinas virtuais não confiáveis, desative o offload de checksum nas interfaces virtio-net dessas máquinas virtuais e aceite a perda de taxa de transferência. Essa configuração não afeta uma VM iniciada por um usuário local para uso próprio; portanto, em hosts com usuários de shell não confiáveis, desative também os namespaces de usuários sem privilégios. Se você compilar seus próprios kernels, mude para uma versão estável fixa do upstream.

Em um host libvirt, verifique se a definição de uma máquina virtual contém configurações explícitas de checksum:

virsh dumpxml <domain> | grep ‘csum=’

Esses atributos só aparecem no XML quando alguém os define. Para uma interface virtio, uma saída vazia significa que os padrões do QEMU estão em vigor, e esses padrões mantêm o offload de checksum ativado.

A versão completa

A hospedagem de VMs multilocatárias se baseia em uma promessa: tudo o que um cliente executa dentro de sua máquina virtual permanece dentro dela. O PwnEscape quebra essa promessa com uma gravação de dois bytes que o kernel do host realiza em si mesmo.

O que torna esse bug incomum é o local onde ele se encontra. Ele não está no KVM e, ao contrário do Januscape e do Zapscape, que surgiram no início deste ano, não requer virtualização aninhada. O bug está no caminho de saída IPv4 comum do host. Uma máquina virtual chega até lá da mesma forma que faz milhares de vezes por segundo: solicitando ao host que calcule uma soma de verificação para ela.

A correção já foi implementada no código-fonte original, mas os kernels das distribuições ainda não foram atualizados, enquanto um relatório detalhado foi publicado junto com o CVE. Até que esses dois se alinhem, os servidores permanecem vulneráveis.

O que realmente aconteceu nesta semana

Paulos Yibelo, do pwn.ai, descobriu a falha no terceiro dia do desafio Vercel Sandbox de US$ 1 milhão. Ele relatou a causa raiz de forma privada aos contatos de segurança do kernel e aos mantenedores de rede em 4 de setembro, e Michael S. Tsirkin, da Red Hat, reproduziu a falha três dias depois.

A série de patches foi disponibilizada publicamente no netdev em 19 de setembro. A correção mais específica de Tsirkin, commit 6785011f8b16, foi aplicada à árvore de rede em 8 de outubro e incorporada ao código principal em 14 de outubro, no mesmo dia em que a Vercel publicou as conclusões de seu desafio. O CVE, sete kernels estáveis e o artigo do pesquisador, “PwnEscape: Guest-to-Host KVM Escape”, foram todos divulgados em 15 de outubro. O artigo explica o bug em detalhes, mas não inclui nenhum código de exploração.

Como dois bytes podem causar um vazamento de memória no host

Os pacotes que chegam pelo TAP, vhost-net ou AF_PACKET podem conter um virtio_net_hdr, um pequeno bloco de dicas de descarregamento fornecidas pelo remetente. Duas dessas dicas, csum_start e csum_offset, informam ao kernel onde começa a região da soma de verificação e onde o resultado deve ser armazenado, e o pacote é marcado como CHECKSUM_PARTIAL para que algum componente a jusante conclua a tarefa.

O ponto fraco está na verificação de entrada. A função `virtio_net_hdr_to_skb()` verifica apenas se `csum_start` está, no mínimo, 20 bytes adiante no buffer. No TAP, esse buffer começa com o cabeçalho Ethernet de 14 bytes; portanto, 20 bytes ficam exatamente dentro do cabeçalho IPv4. Não há nada que compare `csum_start` com o final do cabeçalho IP.

Quando o host precisa fragmentar o pacote, a função `ip_do_fragment()` chama `skb_checksum_help()`, que calcula a soma de verificação e grava dois bytes em `csum_start + csum_offset`. O convidado fornece os dados cuja soma de verificação está sendo calculada; portanto, ele controla efetivamente esses dois bytes. A gravação nunca sai do buffer do pacote. Ela ocorre em um cabeçalho IP que o kernel já analisou, roteou e considerou confiável.

Em seguida, o fragmentador lê esse cabeçalho novamente. No caso do pesquisador, o primeiro byte passou de 0x45 para 0x4f, ainda IPv4, mas o campo de comprimento do cabeçalho (ihl) agora indicava 60 bytes em vez de 20. A função `ip_frag_next()` copia esse número de bytes do cabeçalho para cada fragmento. Os dados lineares válidos do pacote tinham apenas 28 bytes — 20 de cabeçalho e 8 de carga útil —, de modo que os últimos 32 bytes de cada cópia vieram da memória do host, além do fim do pacote. Eles saem do host como opções IPv4 nos fragmentos transmitidos, onde qualquer receptor controlado pelo invasor pode lê-los.

Trinta e dois bytes não é muita coisa, mas o vazamento se repete enquanto o convidado continuar enviando dados. O pesquisador combinou isso com o “heap grooming” para conseguir gravações selecionadas de 64 bytes na memória do kernel do host e, em seguida, executou um programa auxiliar no host como root, em quatro inicializações a frio distintas no laboratório. Essa cadeia de ações não é de domínio público, e a TuxCare não conseguiu reproduzir nada disso.

Como interpretar a nota 9,3

O vetor é AV:L/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H, e a parte AV:L costuma confundir as pessoas.

O que importa é a mudança no escopo. O invasor está em um domínio de segurança, o convidado, e o dano ocorre em outro, o anfitrião. Essa é exatamente a situação que o escopo do CVSS se destina a expressar, e é por isso que uma vulnerabilidade local recebe uma pontuação de 9,3. O NVD ainda não havia publicado sua própria análise até o momento da redação deste artigo; portanto, a pontuação do CNA é a única disponível.

Pelo menos um banco de dados de vulnerabilidades já lista isso como explorável remotamente. Por si só, não é. CHECKSUM_PARTIAL e csum_start são metadados do buffer de pacotes do kernel, não bytes contidos no pacote. As placas de rede nunca os definem a partir de dados recebidos. O GRO pode defini-los, mas apenas a partir de um cabeçalho TCP que o próprio kernel analisou, e somente para pacotes IPv4 sem opções IP. Um pacote manipulado proveniente da internet não consegue chegar até lá.

Um invasor remoto precisa, primeiro, de um ponto de acesso — seja em uma máquina virtual, em um contêiner ou em uma conta local. Em um host de máquinas virtuais multilocatário, esse ponto de acesso custa um cartão de crédito.

Quem consegue alcançar o inseto?

O cenário principal é o de uma máquina virtual convidada não confiável que acessa o host por meio de TAP ou vhost-net, demonstrado tanto em configurações KVM quanto em Firecracker. A máquina virtual convidada não precisa de acesso aos dispositivos do host, pois o VMM já detém o descritor de arquivo TAP e transmite os metadados de descarregamento sem alterações.

Os caminhos locais são menos certos. Dentro de um namespace de usuário, um processo sem privilégios pode ser capaz de abrir o tun com IFF_VNET_HDR, pois o tun verifica o CAP_NET_ADMIN apenas dentro desse namespace, onde o processo detém esse direito. O AF_PACKET com PACKET_VNET_HDR é um caso semelhante, já que requer o CAP_NET_RAW, que também é concedido por um namespace de usuário. Nenhum dos dois casos foi reproduzido. Os namespaces de usuário sem privilégios, habilitados por padrão no EL8 e versões posteriores, são o principal fator de exposição aqui, mas não o único. O acesso a um dispositivo macvtap ou ipvtap existente é uma rota separada, com seus próprios requisitos de permissão. O mesmo vale para uma VM que o usuário inicializa para si mesmo. No EL8 até o EL10, as regras padrão do udev deixam o /dev/kvm com permissão de gravação para todos, de modo que qualquer usuário local pode iniciar uma VM e ter privilégios de root dentro dela. Se essa VM receber um backend TAP ou vhost-net, normalmente por meio de um namespace de usuário, ela poderá enviar ao host os mesmos metadados de offload manipulados que um convidado do cliente enviaria. Servidores de hospedagem compartilhada estão incluídos no escopo, mesmo que nunca executem uma VM de cliente.

Por esse motivo, vale a pena dar uma olhada nos executores de CI compartilhados que compilam o código do cliente em contêineres sem acesso ao diretório raiz, mesmo que o caminho local ainda precise ser testado.

Os hosts que executam máquinas virtuais sobre as quais você não tem controle e os servidores compartilhados que concedem acesso a um shell a usuários não confiáveis têm prioridade; em seguida, vêm outros sistemas que executam código não confiável. Todos os demais apresentam menor exposição conhecida e ainda assim devem receber a correção por meio das atualizações de segurança normais, programadas de acordo com o risco real de cada caso.

O PwnEscape é uma vulnerabilidade “zero day”?

A publicação de Vercel se refere a isso como uma vulnerabilidade zero-day do kernel do Linux e, quando Yibelo a descobriu em agosto, ninguém na comunidade de desenvolvimento sabia de sua existência. No entanto, quando o CVE-2026-99999 foi publicado, a correção já estava incorporada ao código principal. Para quem está se manifestando agora, trata-se de uma divulgação coordenada com uma correção disponível, sem código de exploração público e sem relatos de uso fora do âmbito de pesquisas autorizadas.

O pesquisador prevê que, em questão de semanas, surgirão exploits eficazes contra configurações mais vulneráveis de hipervisores e, em menos de um mês, contra configurações padrão de hipervisores. Considere isso como uma previsão do pesquisador. Os hosts expostos não devem esperar para ver se essa previsão se concretiza.

Quem é afetado?

Status do kernel do fornecedor em 16 de outubro de 2026, independentemente do status dos patches sem reinicialização do KernelCare:

Não determine o status da distribuição com o comando `uname -r`. Os kernels corporativos incorporam correções sem alterar sua versão base; portanto, um kernel EL que pareça mais antigo que a versão 5.10.272 não prova nada, seja a favor ou contra. Somente um comunicado do fornecedor ou um patch verificado que não exija reinicialização para aquele kernel específico resolve a questão.

Adquira o KernelCare hoje mesmo →

Desativando os pré-requisitos até que uma correção seja implementada

Cada uma das opções abaixo remove um pré-requisito. Nenhuma delas foi testada pela TuxCare ainda; portanto, experimente-as primeiro em um sistema convidado não crítico.

O importante para os hosts de VM é não permitir o descarregamento da soma de verificação para máquinas virtuais nas quais você não confia. Ao usar o QEMU diretamente, configure isso no dispositivo:

-dispositivo virtio-net-pci,netdev=n0,csum=desativado,guest_csum=desativado

With libvirt, add <driver><host csum=’off’/><guest csum=’off’/></driver> inside the guest’s <interface> element. Either way it’s per VM, needs a full guest restart, and costs throughput because the guest loses TSO and GSO. Firecracker is the awkward case. It was one of the demonstrated targets, and whether offload can be switched off per VM there hasn’t been verified yet.

Apenas para o caminho local, desative os namespaces de usuários sem privilégios. Registre primeiro o valor atual com o comando `sysctl user.max_user_namespaces` e, em seguida, execute:

sysctl -w user.max_user_namespaces=0

Isso bloqueia novos namespaces de usuário, mas não afeta os já existentes. Para tornar essa configuração permanente, salve-a em um arquivo na pasta /etc/sysctl.d/; para reverter, basta excluir esse arquivo e restabelecer o valor anterior. Essa medida tem um custo real: ela interrompe o funcionamento de contêineres sem privilégios de root, bem como das sandboxes do Chrome e do Flatpak, e não oferece nenhuma proteção contra fugas do sistema convidado. Se apenas contas confiáveis devem executar VMs, uma regra do udev que defina /dev/kvm como 0660 para o grupo kvm também bloqueia a rota da própria VM, embora não a rota direta do tun.

Aplicar o patch e verificar o kernel em execução

Se você compila seus próprios kernels, mude para uma das versões estáveis corrigidas apresentadas na tabela. A instalação de uma dessas versões não altera nada até que o host seja inicializado com ela; portanto, verifique o que está realmente em execução:

uname -r

Um servidor que instalou o novo kernel e nunca reiniciou ainda está executando a versão vulnerável, e os hipervisores são os que mais apresentam esse problema.

Uma vez lançado para o seu kernel, o patch KernelCare sem reinicialização pode aplicar a correção sem a necessidade de reinicialização. Quando as atualizações automáticas estão habilitadas, ele é instalado assim que estiver disponível no feed do kernel em execução, e o comando `kcarectl –update` o solicita sob demanda. Para confirmar a cobertura:

kcarectl –patch-info | grep ‘CVE-2026-99999’

Os patches que não exigem reinicialização já estão em produção para a maioria dos fluxos (veja o status acima); portanto, assim que o seu for aplicado, o comando deverá listar o CVE do kernel em execução e, até que isso ocorra, mantenha as medidas de mitigação em vigor.

Depois, há o acompanhamento. A correção no upstream é pequena: 44 linhas adicionadas e 12 removidas em seis arquivos. Ela adiciona uma função auxiliar, ip_check_csum_start(), que rejeita pacotes cujo csum_start aponta para antes do final do cabeçalho IP, e a chama antes da conclusão da soma de verificação em cinco locais: fragmentação de IP, fragmentação de conntrack da ponte, nfnetlink_queue, xt_CHECKSUM e saída do xfrm. A mensagem de commit se refere à alteração como uma medida de “defesa em profundidade” e afirma que “uma validação mais completa na entrada está por vir”. Portanto, espere uma segunda correção no upstream e, possivelmente, um segundo patch que não exija reinicialização junto com ela. Não feche o ticket da primeira correção.

Por que o PwnEscape é importante

O limite do sistema convidado abrange muito mais do que o hipervisor. Cada parte do código do host que confia no que o sistema convidado afirma sobre seus próprios pacotes está sujeita a ele. Os metadados de descarregamento existem para aumentar a velocidade e, por 18 anos, o kernel aceitou a informação fornecida pelo sistema convidado sobre para onde uma soma de verificação deveria ser enviada.

Se você estiver executando máquinas virtuais de terceiros, desative agora mesmo o offload de checksum em máquinas convidadas não confiáveis. Se você fornecer um shell a outras pessoas, desative os namespaces de usuários sem privilégios. De qualquer forma, aplique a correção no kernel em execução assim que ela estiver disponível para a sua versão. Em seguida, continue acompanhando o desenvolvimento, pois mais validações de entrada estão a caminho. Quando reiniciar um hipervisor significa primeiro evacuar os convidados, o patch “rebootless” do KernelCare tem como objetivo corrigir o bug no kernel em execução assim que for lançado para o seu kernel, sem a necessidade de evacuação ou janela de manutenção.

Adquira o KernelCare hoje mesmo →

Linha do tempo

Referências

As fontes primárias para esta publicação são o registro CVE-2026-99999 publicado pela CNA do kernel em 15 de outubro de 2026, as conclusões da Vercel sobre o desafio “$1M Vercel Sandbox” (14 de outubro de 2026) e o relatório do pesquisador intitulado “PwnEscape: Guest-to-Host KVM Escape (15 de outubro de 2026), o relatório de patch do pesquisador no netdev, a correção upstream 6785011f8b16, o aviso da LWN sobre as sete versões estáveis e a entrada no rastreador de segurança do Debian.