CVE-2026-98432: falha use-after-free no TCP do Linux expõe root remoto via MPTCP

A CVE-2026-98432 é uma falha de use-after-free no caminho IPv4 do handshake TCP do kernel Linux↳Linux34 conteúdosKali Linux em um Servidor VPS: como, quando e por que usar?DevSecOps · dez 2024Construindo um Windows Service ou Linux Daemon com Worker Service & .NET Core – Parte 2Dev (Back & Front) · jul 2020Criando uma WebApi utilizando .NET, Linux e VSCodeDev (Back & Front) · ago 2019Ver tudo em DevSecOps →, documentada pelo processo de CVE do próprio projeto Linux e detalhada pelo Penligent Security Blog em 30 de outubro de 2026. O registro upstream recebeu CVSS 3.1 de 9,8, vetor AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H: ataque via rede, sem autenticação, sem interação do usuário, com impacto alto em confidencialidade, integridade e disponibilidade.

O problema mora na forma como o kernel gerencia o ciclo de vida de opções IP associadas a um request socket durante o handshake. Isso importa porque a falha não exige nenhuma configuração exótica: ela está na rota padrão de atendimento de conexões TCP, que roda em praticamente todo servidor Linux exposto à internet, incluindo gateways, balanceadores de carga, nós de Kubernetes e VPNs.

Onde o bug mora no handshake

Quando um cliente inicia uma conexão, o Linux não aloca um socket completo de imediato: ele cria um request socket leve para validar o handshake antes de comprometer memória com uma conexão real. Ao concluir a troca, a função tcp_v4_syn_recv_sock() transfere o ponteiro ireq_opt do request socket para o campo inet_opt do socket filho, sem duplicar o objeto de opções IP.

O problema aparece quando um segundo SYN retransmitido para a mesma conexão chega enquanto esse processo está em andamento. Esse caminho roda em outra CPU, dentro de uma seção crítica de leitura RCU, através de tcp_check_req(), tcp_v4_send_synack() e inet_csk_route_req(). Funções posteriores, como ip_build_and_send_pkt() e ip_options_build(), leem campos desse mesmo objeto de opções que o primeiro caminho pode já ter liberado.

O destrutor original chamava kfree() diretamente sobre esse objeto, como se nenhum leitor RCU pudesse estar em curso. É exatamente o contrário do que a documentação de RCU do próprio kernel prescreve: remoção de um dado da estrutura e liberação de memória são operações distintas, e confundi-las é uma fonte clássica de use-after-free. A correção, mesclada no upstream como o commit e3f33b0a1d89 ("ipv4: free inet_opt and ireq_opt after an RCU grace period"), troca kfree() por kfree_rcu() nos destrutores inet_sock_destruct() e tcp_v4_reqsk_destructor(), adiando a liberação até o fim do período de graça do RCU.

Uma segunda porta: migração de requisição

Há uma variante do mesmo bug ligada à migração de conexões pendentes entre sockets de escuta. Com net.ipv4.tcp_migrate_req=1 habilitado, ou com um programa BPF usando BPF_SK_REUSEPORT_SELECT_OR_MIGRATE, o kernel pode clonar um request socket e, por um instante, dois objetos de requisição compartilham o mesmo bloco de opções IP. Se o destrutor de um deles libera esse bloco imediatamente, uma CPU que ainda segura referência ao objeto original fica lendo memória já reaproveitada. A correção estende a mesma lógica de kfree_rcu() para esse cenário, afetando quem usa SO_REUSEPORT com seleção de socket via BPF, comum em arquiteturas de alta concorrência.

Root remoto comprovado em laboratório com MPTCP

Em 27 de outubro de 2026, pesquisadores da Anthropic publicaram uma demonstração de execução remota de código como root, sem interação do usuário ("zero-click"), contra um servidor com um listener Multipath TCP (MPTCP) ativo, explorando essa mesma condição de corrida. Segundo o relato, o primeiro estágio do exploit vazou um ponteiro de kernel e derrotou o KASLR (randomização de endereço de memória do kernel) em aproximadamente 48 minutos; o segundo estágio converteu a corrupção de memória em sequestro de fluxo de execução e rodou um comando escolhido pelo atacante como root em cerca de cinco minutos adicionais.

Um detalhe técnico ajuda a explicar por que a corrida é viável: uma tentativa falha pode deixar o handshake incompleto sem necessariamente derrubar o host, o que permite repetir a tentativa várias vezes sem levantar suspeita óbvia. O MPTCP, documentado oficialmente pelo próprio kernel Linux, estende o TCP comum para permitir que uma conexão use múltiplos subfluxos de rede mantendo compatibilidade com aplicações existentes — e muitas distribuições já trazem suporte a MPTCP habilitado mesmo quando a aplicação não pede isso explicitamente.

É importante não esticar essa prova além do que ela mostra. O próprio material da pesquisa não estabelece taxa de sucesso em escala, nem que o mesmo exploit funcione sem alteração em diferentes builds de kernel, arquiteturas de CPU, alocadores de memória e perfis de hardening. A afirmação defensável é: a falha é remotamente alcançável pela rede, a Anthropic demonstrou execução de código como root sem autenticação contra um listener MPTCP vulnerável em ambiente controlado, e a exploração mais ampla depende do alvo.

Por que o CNA, a Red Hat e o Ubuntu discordam do score

A pontuação de 9,8 do registro CNA do Linux descreve o componente upstream no pior cenário plausível. Distribuições específicas avaliam o mesmo defeito contra o código que de fato empacotam, com suas configurações e mitigações. O Ubuntu, por exemplo, mantém o 9,8 em CVSS 3.1 na página pública, mas também publica uma pontuação CVSS 4.0 de 8,3 com requisitos de ataque presentes, o que reflete pré-condições que o vetor mais antigo não capturava bem.

Para ambientes RHEL, a orientação prática é consultar o aviso ativo da Red Hat em vez de aplicar um score upstream genérico a todo produto distribuído. O caso do AlmaLinux ilustra o problema oposto: até o retrato de 30 de outubro de 2026 usado como base desta reportagem, não havia confirmação independente via aviso oficial específico da CVE para essa distribuição — o que não deve ser lido como prova de que o sistema está seguro.

Como validar se o seu servidor está exposto

A resposta prática recomendada pela pesquisa segue uma sequência direta:

1. Mapear quais serviços Linux com TCP estão alcançáveis pela rede, incluindo nós de Kubernetes, proxies reversos e appliances que usam a stack de rede do Linux.
2. Identificar exatamente qual kernel do fornecedor está rodando, sem assumir que uname -r sozinho resolve a questão — distribuições enterprise costumam fazer backport de correções mantendo uma versão base mais antiga na aparência.
3. Instalar o build corrigido fornecido pelo fornecedor e reiniciar para ele entrar em vigor.
4. Guardar evidência (changelog do pacote, metadado de build ou declaração VEX) de que o kernel em execução contém a correção.
5. Dar atenção imediata a hosts com listener MPTCP, porque foi exatamente essa configuração que a pesquisa pública validou como caminho para root remoto.

Equipes que rodam serviços em Go↳Go23 conteúdosEntendendo o Green Tea GC do Go 1.26Dev (Back & Front) · mai 2026Função recursiva em Go para acessar valores em mapas aninhadosDev (Back & Front) · set 2025Publicando projeto desenvolvido em Golang em um server grátisDev (Back & Front) · mar 2025Ver tudo em Dev (Back & Front) → também precisam de atenção específica: um aviso do Go Security Team, arquivado em 30 de outubro de 2026 (anúncio original enviado em 29 de outubro, horário do Pacífico), alerta que programas em Go no Linux podem expor listeners MPTCP mesmo quando quem operou o serviço não escolheu isso deliberadamente. A recomendação é corrigir o kernel em vez de tentar desabilitar MPTCP programa a programa, abordagem descrita como frágil e capaz de deixar outro listener exposto.

O que ainda não está provado

Nenhuma fonte citada aqui estabelece exploração em massa pela internet pública. Volume alto de SYN retransmitido não é, por si só, evidência de exploração: perda de pacote, roteamento assimétrico, sobrecarga de serviço e middleboxes já produzem esse padrão normalmente, e correlacionar isso com indícios reais de use-after-free exige mais do que um alerta de rede. Desativar MPTCP reduz a exposição imediata ao caminho específico usado na pesquisa, mas não remove o defeito de ciclo de vida de memória no IPv4 comum — a correção durável continua sendo o patch do kernel.

Fonte: Hacker News