Falha TCP do Linux sobe para 9,8 no CVSS

A Red Hat elevou, em 2 de novembro, a pontuação CVSS da vulnerabilidade CVE-2026-98432 do kernel Linux para 9,8; antes disso, havia atribuído notas entre 5,9 e 8,1. A empresa lançou kernels corrigidos para RHEL 8, 9 e 10 em 1.º de novembro. No Ubuntu, o estado continua a ser correção em andamento.

A falha está no processo de estabelecimento de conexões TCP sobre IPv4 e pode ser acionada pela rede, sem autenticação e sem qualquer ação do utilizador. O alcance começa no Linux 4.4, e a raiz do problema remonta a um commit de 2015.

Uma condição de corrida corrigida com duas linhas de código

Quando um pacote SYN traz opções IPv4 (como Record Route ou Timestamp), o kernel guarda-as no socket de requisição. Concluído o handshake, o ponteiro para essa memória é passado diretamente ao socket filho, sem cópia, e os dois passam a partilhar a mesma área.

Se, nesse momento, outra CPU estiver a montar um SYN-ACK por causa de um SYN retransmitido e o socket filho for destruído ao mesmo tempo, a memória das opções é libertada de imediato por kfree(). O caminho que constrói o SYN-ACK acaba por ler memória já libertada.

A correção foi enviada por Eric Dumazet, no commit e3f33b0a1d89, e troca kfree() por kfree_rcu(), esperando o fim do período de carência do RCU antes de libertar; mexe em apenas duas linhas. Quem reportou a falha foi Xinyang Ge, da Anthropic. O registo CVE foi publicado em 15 de outubro; as versões corrigidas nos ramos estáveis são 5.10.272, 5.15.223, 6.1.190, 6.6.159, 6.12.113, 6.18.56 e 7.2.10, e na linha principal a 7.3.

A versão da Anthropic só ela própria pode comprovar

O que levou a falha a ganhar atenção foi um artigo da Anthropic Frontier Red Team de 27 de outubro. Segundo o texto, um modelo interno ainda não lançado escreveu para a equipa um programa de exploração que permite a um atacante remoto não autenticado executar comandos como root em servidores com escuta MPTCP ativa.

A exploração tem duas fases: primeiro, a condição de corrida serve para ler memória do kernel fora dos limites, vazar ponteiros e contornar o KASLR; depois, uma escrita fora dos limites sobrescreve um ponteiro de função de callback. A Anthropic indica cerca de 48 minutos para vazar o ponteiro e mais cerca de 5 minutos para obter execução de comandos.

Há vários pontos a separar. O código do exploit, as versões de kernel usadas nos testes e a configuração não foram divulgados, e até agora não há verificação por terceiros. Nem o registo CVE nem o commit de correção mencionam o MPTCP, e o artigo não explica por que razão ele seria indispensável. Os 53 minutos são um número de um ambiente desconhecido e não se aplicam diretamente a servidores em produção. Até 2 de novembro, nenhum fornecedor, CERT ou equipa de CVE do kernel reportou exploração em ambiente real, e o catálogo de vulnerabilidades conhecidas e exploradas da CISA também não a inclui.

Algumas publicações em chinês escrevem que a “Anthropic divulgou exemplos de exploração”. Com mais rigor, o que foi divulgado foi a descrição do processo de exploração, e não código executável.

A divergência na pontuação também persiste. A equipa de CVE do kernel e a Red Hat atribuem agora 9,8, enquanto Oracle, SUSE e Amazon atribuem 8,1; a diferença está em classificar a complexidade do ataque como baixa ou alta. O NVD ainda não publicou a sua própria nota.

O Go transformou o pré-requisito em valor predefinido

O comunicado da equipa de segurança do Go de 29 de outubro ampliou o alcance do problema. Desde o Go 1.24, o valor predefinido de multipathtcp é 2, o que significa ativar o MPTCP apenas do lado de escuta. Ou seja, um programa em Go que inicia um serviço com net.Listen já cumpre, por predefinição, o pré-requisito demonstrado pela Anthropic.

A mitigação sugerida pela equipa do Go é definir GODEBUG=multipathtcp=0 em tempo de execução, ou escrever godebug multipathtcp=0 no go.mod do módulo principal; ao mesmo tempo, a equipa descreve esta desativação programa a programa como “a fragile mitigation” (uma mitigação frágil). Para a equipa do Go, alterar o valor predefinido agora seria prematuro. No kernel, é possível definir net.mptcp.enabled como 0, o que apenas elimina o pré-requisito demonstrado, e a vulnerabilidade em si continua lá.

O que os administradores podem fazer primeiro

O estado das distribuições (parte verificada em 29 de outubro, parte em 2 de novembro) é, em linhas gerais, o seguinte:

O Ubuntu tem um peso considerável entre os utilizadores de servidores na nuvem, pelo que é a linha desta tabela que mais merece atenção. A maioria das distribuições corrige por backport; por isso, para saber se um sistema está corrigido é preciso comparar as versões dos pacotes com o aviso de segurança da própria distribuição, e olhar apenas para a versão principal em uname -r pode induzir em erro. Depois de instalar o novo kernel é necessário reiniciar; o live patching é outro mecanismo e tem de ser confirmado separadamente.

Para máquinas que ainda não podem receber a correção, o primeiro passo pode ser inventariar os serviços que escutam em MPTCP, sobretudo binários compilados com Go 1.24 ou posterior, e depois decidir se os desativa pelos métodos acima. Os fornecedores não confirmaram que desligar o MPTCP elimine todo o risco, pelo que este passo serve apenas para ganhar tempo. Se os registos de falha do kernel mostrarem funções como ip_options_build, convém investigar também.

Fontes: relatos públicos do artigo da Anthropic Frontier Red Team, boletim de vulnerabilidade da Rescana, CocoLoop, comunicado da equipa de segurança do Go, páginas de acompanhamento de segurança do Debian e da Red Hat; as pontuações e o estado das correções seguem o que cada fornecedor divulga, e os detalhes de exploração da Anthropic não foram verificados de forma independente.