PwnEscape: falha no kernel Linux pode expor memória do host

PwnEscape, nome dado pelo pesquisador Paulos Yibelo à CVE-2026-99999, é uma falha no processamento de rede IPv4 do kernel Linux, alcançável por um caminho que parte de uma máquina virtual convidada e passa por configurações como KVM com virtio-net. O defeito está no kernel do host, não no código do KVM.

Isso importa porque uma falha no processamento de pacotes do host pode atravessar a fronteira entre a máquina virtual e o sistema que a executa. Yibelo relata uma divulgação repetível de 32 bytes de memória; a execução como root foi uma demonstração separada, feita em um ambiente de pesquisa próprio.

Onde está a falha

O caminho vulnerável fica na rede IPv4 do kernel Linux do host. KVM e virtio-net podem permitir que metadados de checksum originados na máquina virtual cheguem a esse caminho, mas não são o componente com defeito. Atualizar apenas o kernel dentro da máquina convidada não corrige a falha no host.

Como os metadados de checksum expõem memória

O relato técnico de Yibelo descreve uma conclusão adiada do checksum que pode sobrescrever parte de um cabeçalho IPv4 já processado. Em seguida, a fragmentação usa o tamanho de cabeçalho alterado, conforme a descrição técnica de PwnEscape.

No caso estudado, o campo IHL, que indica o comprimento do cabeçalho IPv4, passou de uma interpretação de 20 bytes para 60 bytes. O pacote tinha 28 bytes de dados lineares lógicos: 20 do cabeçalho original e 8 da carga útil. Com o cabeçalho reinterpretado como tendo 60 bytes, a fragmentação copiou 32 bytes além desse limite lógico, expondo memória do host.

Esse resultado delimita a divulgação descrita por Yibelo: ele relata uma exposição repetível de 32 bytes por caso ativo, não um resultado idêntico para todo pacote ou host.

O que a pesquisa demonstrou

A divulgação de memória e a execução como root foram resultados distintos. Em uma configuração KVM própria, Yibelo também relata gravações selecionadas de 64 bytes e uma cadeia de execução de um auxiliar que chegou a root em quatro inicializações completamente a frio. Essa demonstração ocorreu no ambiente de pesquisa controlado por ele.

O que a correção upstream muda

O patch aceito no kernel Linux acrescenta ip_check_csum_start() e verifica a posição inicial do checksum antes de concluir a operação em cinco pontos de consumo. A mudança barra posições de início dentro do cabeçalho IPv4; Yibelo a descreve como uma defesa em profundidade, não como uma reformulação completa da validação de entrada. O commit do kernel registra a alteração.

Em 15 de outubro de 2026, o The Hacker News listou como corrigidos no upstream os marcos 5.10.272, 5.15.223, 6.1.190, 6.6.159, 6.12.113, 6.18.57 e 7.2.11 em sua relação de versões. Distribuições podem incorporar a correção em pacotes com outra numeração; por isso, os números upstream não substituem a versão indicada pelo fornecedor do kernel do host.

O que a AWS diz sobre seus serviços

No boletim publicado em 15 de outubro de 2026, a AWS distinguiu os serviços que administra dos hosts KVM/virtio-net operados pelos clientes. A orientação para atualizar o kernel do host e reiniciar se aplica aos hosts autogerenciados afetados e sem correção. O boletim de segurança da AWS detalha esse escopo.

A declaração sobre os serviços gerenciados não se estende aos hosts que o cliente administra. Para esses sistemas, é o kernel do host que precisa receber a correção e ser carregado após a reinicialização.

Por que há duas notas CVSS

As duas avaliações CVSS 3.1 usam métricas diferentes para os privilégios necessários, conforme o aviso da Red Hat.

PR:N e PR:L representam pressupostos distintos sobre os privilégios exigidos. Por isso, cada nota precisa ser lida junto da avaliação a que pertence.