Voltar

2026/11/04

CVE-2026-98432: use-after-free no TCP do Linux, root remoto assistido por IA via MPTCP e defesas para Linux empresarial

Uma corrida no TCP IPv4 do Linux, um root remoto demonstrado via MPTCP e as correções e mitigações para RHEL, Ubuntu, Oracle Linux e Debian.

Informações verificadas em: 3 de novembro de 2026 | Análise técnica da LOGIQ

Em outubro de 2026, foi divulgada uma vulnerabilidade de use-after-free (UAF), a CVE-2026-98432, no tratamento de conexões TCP IPv4 do kernel Linux. A equipe de CVE do kernel Linux publicou o seu aviso em 15 de outubro. Em 27 de outubro, a Anthropic relatou que um modelo interno de pesquisa ainda não lançado demonstrou a execução remota de comandos, sem autenticação e com privilégios de root, contra um servidor Linux com um listener MPTCP (Multipath TCP). É fundamental não confundir as condições específicas desse exploit com os riscos mais amplos de vulnerabilidade e de negação de serviço que afetam os serviços TCP IPv4 comuns.

Pontos principais

  • A falha é uma condição de corrida no tratamento comum de pedidos de conexão TCP IPv4, presente desde o Linux 4.4. O MPTCP não é necessário para que o bug exista.
  • A demonstração de root remoto da Anthropic visou um servidor com um listener MPTCP; outros serviços TCP continuam expostos a falhas, negação de serviço e corrupção de memória.
  • A Red Hat classifica o problema como Critical (CVSS v3.1 9.8) e lançou kernels corrigidos para o RHEL 8, 9 e 10 em 1 de novembro. As correções do Ubuntu ainda estavam em andamento em 3 de novembro.
  • Instale um kernel corrigido aprovado pelo fornecedor, reinicie e confirme o kernel em execução. As mitigações reduzem a exposição, mas não substituem o patch.

Onde ocorre a condição de corrida

O problema envolve o three-way handshake do TCP IPv4. As opções IP mantidas por um request socket (ireq->ireq_opt) podem ser transferidas para o inet_opt do socket filho durante tcp_v4_syn_recv_sock() sem serem copiadas. Se outra CPU estiver processando um SYN retransmitido e montando um SYN/ACK enquanto o socket filho é destruído, a memória das opções pode ser liberada ainda em uso. Um acesso posterior por funções como ip_options_build() pode desencadear um UAF.

Existe uma condição de corrida relacionada na migração de request sockets via net.ipv4.tcp_migrate_req=1 ou BPF_SK_REUSEPORT_SELECT_OR_MIGRATE, em que os dados de opções podem ser compartilhados entre o request socket original e o clonado. O comportamento vulnerável remonta ao Linux 4.4, mas a exposição real deve ser avaliada para cada kernel de fornecedor, incluindo backports.

O commit de correção upstream e3f33b0a1d89 (“ipv4: free inet_opt and ireq_opt after an RCU grace period”) altera a desalocação imediata em inet_sock_destruct() e tcp_v4_reqsk_destructor() para uma desalocação adiada por RCU através de kfree_rcu(). O aviso de CVE do Linux identifica correções nas versões de kernel 6.12.113, 6.18.56, 7.2.10 e 7.3-rc7. O caminho IPv6 inicial não é a mesma vulnerabilidade, embora um caminho de migração IPv6 envolvendo CALIPSO seja tratado por um patch separado.

Não confunda o root remoto demonstrado com a exposição geral

A prova de conceito da Anthropic visou um servidor com um listener MPTCP e combinou um vazamento de informações de endereços do kernel com o sequestro do fluxo de controle. O experimento relatado levou cerca de 48 minutos para obter o vazamento de informações e mais cinco minutos para conseguir a execução de comandos. Como uma corrida perdida apenas faz falhar o handshake, em vez de derrubar o sistema, o atacante pode continuar tentando. No entanto, o UAF subjacente está no tratamento comum de pedidos de conexão TCP IPv4, e não exclusivamente no código MPTCP.

A mesma técnica de exploit de root remoto não foi demonstrada para todos os serviços TCP convencionais sem MPTCP. Ainda assim, também é incorreto supor que desativar o MPTCP torna um sistema totalmente seguro. A Red Hat afirma que o MPTCP não é uma condição necessária, que sistemas com o MPTCP desativado (o padrão) continuam afetados, e alerta para falhas remotas sem autenticação, negação de serviço e corrupção de memória em serviços TCP IPv4 padrão.

Avaliações primárias dos fornecedores: gravidade e estado da correção

Estado verificado em 3 de novembro de 2026. As páginas dos fornecedores mudam; consulte sempre a entrada atual antes de agir.

FornecedorGravidadeEstado da correção
Red HatCritical, CVSS v3.1 9.8Kernels corrigidos lançados em 1 de novembro: RHEL 8 (RHSA-2026:93414; kernel-rt para NFV RHSA-2026:93415), RHEL 9 (RHSA-2026:93412), RHEL 10 (RHSA-2026:93413). O kernel-rt do RHEL 9 e o OpenShift (RHCOS) ainda constam como Affected. RHEL 6 e 7 não afetados.
UbuntuPrioridade High; CVSS 9.8linux para 26.10, 26.04, 24.04 e 22.04: Vulnerable, work in progress. 20.04, 18.04 e 16.04: Vulnerable. Nenhum pacote corrigido lançado ainda.
Oracle LinuxImportant; CVSS provisório 8.1Errata do UEK datadas de 16 de outubro (ELSA-2026-500397, -500398, -500399) para OL7 a OL10. Errata do RHCK datadas de 2 de novembro para OL8 (ELSA-2026-93414) e OL10 (ELSA-2026-93413); ainda sem erratum RHCK listado para OL9.
Debian(Security Tracker)Corrigido no bookworm 6.1.190-1 (DLA-4841-1), bookworm linux-6.12 6.12.113-1~deb12u1 (DLA-4850-1) e trixie 6.12.113-1 (DSA-6568-1); forky e sid corrigidos.

Red Hat (avaliação revisada em 30 de outubro; boletim atualizado pela última vez em 2 de novembro). A página oficial da CVE classifica o problema como Critical, CVSS v3.1 9.8, porque um atacante remoto sem autenticação pode corromper a memória do kernel ou derrubar um sistema através de tráfego TCP IPv4 comum. RHEL 8, 9, 10 e OpenShift constam como afetados; o kernel do RHEL 7 consta como não afetado porque o código em questão não existe nele. Desde 1 de novembro, os dados de CVE da Red Hat listam kernels corrigidos: kernel-4.18.0-553.182.1.el8_10 (RHEL 8), kernel-5.14.0-687.64.1.el9_8 (RHEL 9) e kernel-6.12.0-211.72.1.el10_2 (RHEL 10). O boletim de segurança RHSB-2026-016 ainda estava marcado como em andamento e é onde se encontra o procedimento de mitigação. Não apresente pontuações mais antigas de fontes secundárias, como 5.9 ou 8.1, como a avaliação atual da Red Hat.

Ubuntu (tabela oficial atualizada pela última vez em 30 de outubro). O CVSS da CVE é 9.8, enquanto a prioridade atribuída pelo próprio Ubuntu é High. Os pacotes linux padrão do Ubuntu 26.10, 26.04, 24.04 e 22.04 estão marcados como “Vulnerable, work in progress”, com as versões de correção previstas indicadas na página; o 20.04 está marcado como Vulnerable, entre outros estados. As variantes de kernel AWS, Azure, HWE, RT e outras devem ser avaliadas individualmente. “Work in progress” não significa que uma correção já foi lançada.

Oracle Linux. A avaliação da própria Oracle é Important, com uma pontuação CVSS provisória de 8.1. As errata do UEK para OL7, OL8, OL9 e OL10 têm data de 16 de outubro, e as errata do RHCK para OL8 e OL10 vieram em seguida, em 2 de novembro. As correções no UEK não devem ser generalizadas para o RHCK nem para todas as versões menores; avalie o kernel instalado e a errata exata.

Debian. O Security Tracker oficial marca como corrigidos, entre outros, o bookworm-security 6.1.190-1 e o trixie-security 6.12.113-1. Verifique tanto as versões dos pacotes instalados como o kernel em execução após o reinício.

Os resultados de CVSS podem diferir entre a CNA e os fornecedores devido a configurações e correções específicas de cada distribuição, e as avaliações podem mudar. Registe sempre a data de verificação e inclua o link para cada fonte oficial.

Ações defensivas: a mitigação não substitui o patch

A primeira prioridade é instalar um kernel corrigido aprovado pelo fornecedor e verificar a versão em execução após o reinício. Onde ainda não houver correção disponível, considere fechar serviços TCP públicos desnecessários, restringir as redes de origem permitidas e priorizar o monitoramento dos hosts expostos.

O boletim da Red Hat descreve uma mitigação com nftables que descarta os pacotes TCP IPv4 de entrada que transportam opções IP no cabeçalho IPv4:

table inet cve_2026_98432 {
  chain input {
    type filter hook input priority -310; policy accept;
    ip protocol tcp ip hdrlength > 5 counter drop
  }
}

Não é uma proteção completa, pode afetar cargas de trabalho que dependem de opções IP e deve ser testada quanto ao impacto no tráfego de negócio antes da implantação. As opções TCP comuns no cabeçalho TCP continuam permitidas; não se trata de bloquear o campo TCP Options. No OpenShift, as regras ao nível do nó não filtram o tráfego entre pods dentro da rede do cluster, por isso a filtragem no limite da rede é importante nesse caso. Remova a tabela assim que o kernel corrigido estiver em execução.

Dica: Após aplicar o patch, compare uname -r com a versão corrigida indicada no erratum do seu fornecedor e guarde essa saída junto com o registro de alteração. Um pacote instalado que ainda não foi inicializado não elimina a vulnerabilidade.

No Linux, o pacote net do Go, a partir do Go 1.24, ativa o MPTCP para listeners por padrão. A equipe do Go documenta GODEBUG=multipathtcp=0 como forma de o desativar (também disponível como uma linha godebug em go.mod). Uma proposta para alterar o padrão ainda está em discussão, e os mantenedores do Go indicam um kernel corrigido como a verdadeira solução. A configuração pode reduzir a exposição ao caminho de ataque dependente de MPTCP demonstrado pela Anthropic, mas não corrige o UAF do kernel em si. Revise o uso de MPTCP serviço a serviço.

A perspectiva da LOGIQ

Na manutenção de Linux empresarial, não é possível determinar a segurança apenas a partir de uma pontuação CVSS pública ou de uname -r. Avalie em conjunto a versão do sistema operacional, a família de kernel (UEK ou RHCK, por exemplo), a versão do pacote, o kernel atualmente em execução, a exposição de rede, as configurações de MPTCP, as errata do fornecedor e as evidências de reinício. Acompanhe toda a cadeia, desde a avaliação de impacto e a validação até a implantação e o monitoramento operacional.

Quando as correções dos fornecedores estiverem pendentes, documente o risco residual das mitigações temporárias e reavalie-as depois que os patches chegarem. À medida que a IA aumenta a explorabilidade prática das vulnerabilidades, a manutenção empresarial deve cobrir todo o ciclo de vida: detecção, verificação, correção e evidência de funcionamento saudável.

Fontes primárias e referências