CVE-2026-98432

01Sumário executivo

A CVE-2026-98432 é uma condição de corrida que leva a uso após liberação (use-after-free) no código do kernel Linux que monta novas conexões TCP por IPv4 [1] [2]. Afeta kernels desde a versão 4.4 [1]. A equipe de CVE do kernel atribuiu 9.8 em CVSS 3.1; a Red Hat começou classificando como negação de serviço, com 5.9, e elevou para crítica em 30 de outubro [1] [2].

O ataque exige que o atacante alcance uma porta TCP aberta e vença uma corrida com pacotes que carregam opções IPv4, como Record Route ou Timestamp [2]. Perder a corrida só faz a conexão falhar, então o atacante pode repetir quantas vezes quiser [2] [3]. A Anthropic relatou que um modelo Claude de pesquisa, ainda não lançado, construiu um exploit que vaza memória do kernel, contorna o KASLR (Kernel Address Space Layout Randomization), desvia o fluxo de execução do kernel e executa um comando do atacante como root, contra um servidor com ouvinte MPTCP (Multipath TCP) [1] [4]. O exploit não foi publicado [2].

A correção existe no kernel oficial desde 11 de outubro, nas versões 7.2.10 e 6.18.56, e chegou aos demais ramos estáveis em 15 de outubro [2]. As distribuições demoraram: em 30 de outubro, Ubuntu e Red Hat ainda não tinham kernel corrigido; a Red Hat entregou o seu em 1º de novembro, e o Ubuntu seguia vulnerável nessa data [1] [2].

A ação é: instale o kernel corrigido da sua distribuição e reinicie; até lá, bloqueie pacotes IPv4 TCP com opções IP na entrada e tire os ouvintes MPTCP da internet [1] [2] [3]. A seção 6 traz a verificação da infraestrutura do CiberLab.

02Identificação do objeto analisado

03Contexto técnico: o aperto de mão TCP e o MPTCP

3.1O pedido de conexão e o socket filho

Uma conexão TCP começa com três pacotes: o cliente envia SYN, o servidor responde SYN-ACK e o cliente confirma com ACK. Entre o SYN e o ACK, o kernel guarda um pedido de conexão (request socket) com o que aprendeu do SYN, inclusive as opções do cabeçalho IPv4, no campo ireq_opt [1]. Quando o ACK chega, o kernel cria o socket filho, a conexão de fato, e transfere a ele o que estava no pedido [1]. Se o SYN-ACK se perde, o cliente retransmite o SYN, e o kernel responde de novo a partir do mesmo pedido [1].

3.2Opções IPv4

O cabeçalho IPv4 tem uma área opcional para instruções como Record Route, que pede que cada roteador anote seu endereço, e Timestamp, que pede marcas de tempo [2]. Esses campos são raros no tráfego normal da internet, e pacotes com cabeçalho maior que o mínimo de 20 bytes são identificáveis pelo campo de tamanho do cabeçalho [2].

3.3RCU, a leitura sem trava

O kernel usa RCU (Read-Copy-Update) para permitir leituras muito rápidas de estruturas compartilhadas: o leitor não pega trava, e quem libera a estrutura precisa esperar um período de carência, até que todos os leitores tenham saído, antes de devolver a memória [1] [2]. Liberar com kfree() sem esperar esse período quebra a garantia, e é esse o defeito da falha [2].

3.4MPTCP

O Multipath TCP permite que uma única conexão use vários caminhos de rede ao mesmo tempo, comum em aparelhos com Wi-Fi e rede celular [1]. É opcional no Linux, mas há programas que o ativam sem que o administrador perceba: desde a versão 1.24, a linguagem Go abre ouvintes TCP como MPTCP por padrão quando o kernel suporta [1] [2]. Configurações por eBPF também podem forçar aplicações a usá-lo [4].

04Mecanismo da vulnerabilidade e causa raiz

4.1A corrida

Ao criar o socket filho, tcp_v4_syn_recv_sock() passa ireq->ireq_opt para newinet->inet_opt sem copiar, e a estrutura é liberada imediatamente com kfree() quando deixa de ser necessária [1] [2]. Ao mesmo tempo, outro núcleo pode estar processando um SYN retransmitido do mesmo pedido e enviando um SYN-ACK a partir de tcp_check_req() [1]. As funções tcp_v4_send_synack() e inet_csk_route_req() leem ireq->ireq_opt só sob rcu_read_lock(), e ip_build_and_send_pkt() e ip_options_build() leem o campo opt->optlen duas vezes [1]. Se a memória for liberada e reaproveitada entre as duas leituras, o kernel monta o pacote de resposta com um tamanho e um conteúdo que não correspondem mais à estrutura original.

O aviso do kernel registra um segundo caminho para o mesmo efeito: a migração de pedidos de conexão entre sockets, quando net.ipv4.tcp_migrate_req está ligado ou um programa BPF do tipo BPF_SK_REUSEPORT_SELECT_OR_MIGRATE está em uso [1].

4.2Do uso após liberação ao root

Segundo a equipe de CVE do kernel, o defeito pode vazar memória do kernel para o par remoto, dentro do próprio SYN-ACK, causar escrita fora dos limites no kernel ou derrubá-lo [2]. O exploit descrito pela Anthropic encadeia esses efeitos: usa o vazamento para descobrir um ponteiro do kernel e contornar o KASLR, em cerca de 48 minutos, e depois sequestra o fluxo de execução para rodar um comando como root, em cerca de 5 minutos [2] [3] [4].

4.3A correção

O commit de Eric Dumazet troca duas chamadas kfree() por kfree_rcu(), que adia a liberação de inet_opt e ireq_opt até o fim do período de carência do RCU [2]. É uma mudança de duas linhas que fecha a corrida sem alterar o comportamento do protocolo.

05Exploração e estado das correções

A tabela reúne a cronologia, da correção ao estado das distribuições:

Não havia exploração em campo confirmada nem inclusão no catálogo KEV até 1º de novembro [1] [2]. Em 1º de novembro, 41 repositórios públicos no GitHub mencionavam a CVE, e ao menos sete descreviam um gatilho da corrida ou uma prova de conceito, sem verificação independente [2].

06Verificação: a exposição do CiberLab

A falha é do kernel do host, e não da aplicação, então a verificação olhou para onde o CiberLab roda e para quem abre ouvintes TCP. A conclusão é que a aplicação não aciona MPTCP, mas o kernel dos servidores precisa ser conferido.

07Detecção e inventário

7.1Inventário

O primeiro passo é saber qual kernel está rodando, e não qual está instalado, e onde há ouvintes MPTCP [2] [3]:

# Kernel em execucao (difere do instalado ate o reinicio)
uname -r
uname -v

# Kernels instalados
dpkg -l 'linux-image*'      # Debian e Ubuntu
rpm -q kernel               # familia RHEL
needs-restarting -r         # RHEL: reinicio pendente?

# Ouvintes TCP e MPTCP
ss -ltnp
ss -Mlnp
sysctl net.mptcp.enabled

net.mptcp.enabled ligado não prova que exista um ouvinte vulnerável; o que importa é a saída de ss -Mlnp [3].

7.2Tráfego

Pacotes IPv4 TCP com opções IP são raros no tráfego da internet. Uma rajada de SYN com opções Record Route ou Timestamp contra a mesma porta, com retransmissões, é o padrão da corrida [2] [3]. A regra abaixo alerta esse padrão em sensores de borda:

alert tcp $EXTERNAL_NET any -> $HOME_NET any (msg:"CIBERLAB LINUX CVE-2026-98432 TCP SYN WITH IPV4 OPTIONS BURST"; \
    flags:S,12; ipopts:any; \
    threshold:type both, track by_src, count 50, seconds 60; \
    classtype:attempted-admin; sid:9000311; rev:1; \
    reference:cve,2026-98432; reference:url,ciberlab.seg.br/reports/linux-tcp-uaf;)

7.3Sinais no host

Observe quedas repetidas do kernel, falhas inexplicadas de ouvintes e tráfego de entrada com opções IPv4 [3]. Processos com privilégio de root que surgem depois desse tipo de atividade justificam isolar a máquina e preservar evidências [3]. Depois do reinício, confira systemctl --failed e journalctl -k -b -p warning [3].

08Mitigação e resposta a incidentes

8.1Correção definitiva

Instale o kernel corrigido pelo caminho normal da distribuição e reinicie numa janela aprovada [3]. Não aplique o commit do upstream à mão num kernel de produção de distribuição [3]. A condição de encerramento é cada servidor rodando um kernel que a distribuição confirma como corrigido, e os ouvintes de maior risco verificados quanto a sinais de exploração anterior [3].

8.2Medidas temporárias

Enquanto o kernel não é atualizado, a medida mais eficaz é descartar pacotes IPv4 TCP com opções antes que cheguem ao código vulnerável [1] [2]:

table ip cve_2026_98432 {
    chain prerouting {
        type filter hook prerouting priority -300; policy accept;
        ip protocol tcp ip hdrlength gt 5 drop
    }
}

1. Use nftables no RHEL 9 e 10: a alternativa com iptables depende do módulo xt_u32, que não existe nessas versões [2]. As duas regras somem no reinício [2].
2. Desligue o MPTCP: net.mptcp.enabled=0 e reinicie os serviços com ouvintes MPTCP; contêineres precisam do ajuste no próprio namespace [2]. Em programas Go, GODEBUG=multipathtcp=0 desliga o padrão, o que a equipe do Go considera frágil [2].
3. Reduza o alcance: coloque os ouvintes atrás de VPN, firewall ou balanceador confiável e restrinja interfaces de gerenciamento [1] [3].

8.3Resposta a um comprometimento

O reinício depois da atualização impede novo disparo, mas não remove persistência nem credenciais roubadas antes dele [3]. Num servidor com sinais da seção 7.3 e kernel vulnerável exposto, preserve memória e registros antes de reiniciar, gire as credenciais acessíveis ao host e reconstrua a partir de imagem limpa.

8.4Mapeamento de técnicas MITRE ATT&CK

IDs e nomes conferidos na base oficial do MITRE ATT&CK for Enterprise [5]:

09Indicadores de comprometimento

Nenhuma fonte publicou IPs, domínios, hashes ou assinaturas de exploração [2] [3]. Os indicadores abaixo são de exposição e de comportamento:

10Limitações da análise

1. Ausência de detonação: o CiberLab não reproduziu a corrida, não executou exploit e não testou as regras de filtragem. Causa raiz, versões e mitigações vêm das referências [1] a [4].
2. Exploit não publicado: os tempos de 48 e 5 minutos e a dependência do MPTCP vêm da descrição da Anthropic, relatada por terceiros [2] [4]. O exploit não foi publicado, e o CiberLab não teve acesso ao relato original da Anthropic.
3. Estado das distribuições muda rápido: as tabelas 4 e 5 refletem as fontes até 1º de novembro. Confira o rastreador da sua distribuição antes de agir.
4. Divergência de pontuação: a Red Hat partiu de 5.9 e elevou a classificação depois [1] [2]; este relatório adota a nota da equipe de CVE do kernel.
5. Regra derivada: a regra Suricata da seção 7.2 foi deduzida da condição de disparo descrita em [2], com limiar arbitrário, e não foi testada.
6. Infraestrutura não inspecionada: o kernel dos servidores de produção e do Gitea, e a versão do Go usada para compilar o Gitea, não foram verificados.