CVE-2026-98432 no TCP do kernel Linux: o Ubuntu ainda não liberou a correção, e desligar o MPTCP não resolve · tifon

Se você tem servidor Linux exposto na internet, esta merece atenção hoje. A CVE-2026-98432 é um use-after-free por condição de corrida no código que estabelece conexões TCP IPv4 no kernel, presente desde o 4.4. Basta alcançar uma porta TCP aberta, sem autenticação: o atacante manda SYNs com as opções IPv4 Record Route ou Timestamp e retransmite até vencer a corrida. O time de CVE do kernel dá 9.8, e a Red Hat, que tinha dado 5.9, subiu para 9.8 em 01/11.

O que chamou atenção foi quem achou. A correção credita Xinyang Ge, pesquisador da Anthropic, e em 27/10 a Anthropic disse que um modelo Claude ainda não lançado escreveu um exploit de root remoto, sem autenticação, para servidores com listener MPTCP, contornando o KASLR. Pelo relato, são duas etapas: vazar um endereço do kernel (48 minutos no teste) e sobrescrever um ponteiro de callback para rodar um comando como root (mais 5). Corrida perdida só derruba aquela conexão, então dá para insistir. Mas não publicaram código, versão de kernel nem configuração, e o time de kernel da CloudLinux diz que não conseguiu reproduzir. O que existe em público é uma prova de conceito no GitHub que dispara a corrida e detecta o kernel devolvendo memória liberada num SYN-ACK, sem execução de código. Até agora ninguém relatou exploração real, e a falha não estava no KEV da CISA em 30/10.

O bug, em poucas linhas

No handshake, o kernel guarda as opções IP do SYN junto com a requisição pendente. Quando a conexão se completa, tcp_v4_syn_recv_sock() passa essas opções para o socket filho sem copiar. Se o cliente retransmitiu o SYN, outra CPU pode estar montando um SYN-ACK para a mesma requisição, lendo as opções só sob rcu_read_lock(). Se o socket filho for destruído nesse meio-tempo, inet_sock_destruct() libera as opções com um kfree() comum, e ip_options_build() lê memória já liberada.

A janela abriu quando o commit 079096f103fa tirou o processamento dos request sockets de baixo do lock do listener. A correção ("ipv4: free inet_opt and ireq_opt after an RCU grace period") troca o kfree() por kfree_rcu() nesse destrutor e em tcp_v4_reqsk_destructor(), que tem o mesmo problema na migração de request sockets. É o RCU pela metade: os leitores usavam RCU, mas quem liberava não esperava o grace period. O IPv6 escapa da corrida principal porque copia as opções.

O MPTCP e o Go

O exploit da Anthropic usa um listener MPTCP, que normalmente vem desligado. Só que desde o Go 1.24 o runtime liga o MPTCP nos listeners TCP do Linux quando o kernel suporta, então um serviço em Go pode estar com MPTCP aberto sem ninguém ter pedido. Para ver:

sysctl net.mptcp.enabled   # 1 = o kernel aceita MPTCP
ss -Mltn                   # listeners MPTCP abertos

Mas cuidado com a conclusão. O Ubuntu diz que a falha não é específica do MPTCP (o TCP comum também dispara o bug) e chama de errado o conselho de só desligar o MPTCP. A equipe de segurança do Go também acha frágil desligar programa por programa. O MPTCP é o caminho do exploit conhecido, não o tamanho do problema.

O que atualizar

Corrigir é instalar o kernel novo e reiniciar (a AWS diz que livepatch também resolve).

Kernel compilado por você: 5.10.272, 5.15.223, 6.1.190, 6.6.159, 6.12.113, 6.18.56, 7.2.10 ou 7.3. O time do kernel recomenda ir para o estável mais recente em vez de pinçar o patch.
Debian: 6.1.190-1 (Bookworm) e 6.12.113-1 (Trixie).
RHEL 8, 9 e 10: corrigidos em 01/11 (RHSA-2026:93414, 93412 e 93413). O RHEL 7 não é afetado.
Amazon Linux 2 e 2023: kernel corrigido. Nó do EKS na AMI v20261031 ou mais nova, ECS em EC2 na AMI otimizada 20261031; tarefa do Fargate iniciada depois de 01/11 às 6h PDT já sobe corrigida. O Lambda não é afetado.
Oracle Linux e SUSE: já publicaram correção.
Rocky 8, 9 e 10: afetados, com correção pendente nas últimas notícias.
Ubuntu: é o ponto fraco. Conferi hoje (03/11) no rastreador da Canonical, e 22.04, 24.04 e 26.04 continuam "Vulnerable, work in progress": a correção está só no -proposed, sem data para o canal normal. Quem não pode esperar habilita o -proposed, instala o metapacote do kernel (linux-generic, linux-aws...) com apt install -t <release>-proposed --only-upgrade e reinicia, sabendo que é canal de teste. Do 20.04 para trás, só com o Ubuntu Pro (ESM).

Depois do reboot, uname -r mostra se o kernel novo subiu.

Enquanto não dá para reiniciar

Red Hat, CIQ, AWS e o próprio Ubuntu publicaram regras que descartam pacote TCP IPv4 com opções IP, que é o gatilho conhecido. A do Ubuntu, em nftables:

printf '%s\n' 'table inet cve_2026_98432 { chain input { type filter hook input priority -310; policy accept; ip protocol tcp ip hdrlength > 5 counter drop } }' \
  | sudo tee /etc/cve-2026-98432.nft >/dev/null
sudo nft -c -f /etc/cve-2026-98432.nft && sudo nft -f /etc/cve-2026-98432.nft

O ip hdrlength > 5 pega todo cabeçalho IPv4 com mais de 20 bytes, isto é, com opções. Três ressalvas: quebra o que depende de opções IPv4 (raro, mas existe); vale só para o host, então container com rede própria precisa da regra à parte, e um membro do time de kernel da CIQ apontou na oss-security que tráfego entre containers no mesmo host passa por fora dela; e reduz o risco, não elimina. É para ganhar tempo até o reboot.

Fontes: rastreador do Ubuntu e aviso da Fortinet. Reportagens: The Hacker News, BleepingComputer, Aikido e GBHackers.