CVE no TCP do Linux: a correção só conta quando o kernel certo está em execução

A CVE-2026-98432 envolve uma condição de corrida no estabelecimento de conexões TCP IPv4 que pode resultar em uso de memória já liberada.[2] A Anthropic afirma ter obtido execução remota como root em servidores com um listener Multipath TCP, mas não publicou o exploit, a versão do kernel nem a configuração do teste.[2] A reportagem não aponta exploração em ataques reais nas fontes consultadas.[2]

O que muda para quem desenvolve

O desafio operacional não termina no anúncio de uma correção. No retrato de 29 de outubro apresentado pela matéria, Ubuntu e RHEL ainda não tinham pacote corrigido, enquanto outras distribuições ofereciam correções apenas para determinadas linhas.[2] Essa é uma situação datada, não uma garantia sobre a disponibilidade no momento de uma manutenção futura.

A equipe de CVEs do kernel atribuiu nota 9,8, mas fornecedores apresentaram avaliações diferentes de severidade e complexidade.[2] Use essa divergência como convite para examinar as condições de exposição, não como licença para escolher a menor nota e encerrar o assunto.

Para organizar a decisão, separe quatro evidências: versão e pacote instalados, orientação do distribuidor, serviços alcançáveis e kernel efetivamente em execução. Uma lista de vulnerabilidades sem esses vínculos ajuda pouco a decidir uma janela de intervenção.

Como aplicar

Monte uma tabela por host com distribuição, linha suportada, pacote corrigido informado pelo fornecedor e responsável pela manutenção. Acrescente uma coluna para registrar a confirmação após a atualização. Evite marcar como concluída uma tarefa que comprova apenas o download do pacote.

Em homologação, proponha uma manutenção completa: aplicar a atualização suportada, executar o procedimento de ativação previsto e conferir novamente a versão ativa. Em seguida, verifique saúde dos serviços e registre um caminho de retorno. O experimento deve validar a operação, não tentar reproduzir uma exploração cuja configuração não foi publicada.

Para workloads em containers, inclua o host na avaliação. Atualizar somente a imagem da aplicação não deve ser aceito como evidência suficiente de correção do kernel subjacente.

Cuidados e limites

A reportagem informa que programas Go desde a versão 1.24 solicitam MPTCP por padrão para sockets de escuta e descreve formas de desativar esse comportamento.[2] Também ressalta que chamadas explícitas a SetMultipathTCP prevalecem e que a equipe Go considera essa mitigação frágil.[2]

A associação do exploit a MPTCP vem do relato da Anthropic, não de uma limitação expressa no registro da CVE.[2] Logo, não transforme um ajuste de MPTCP em substituto comprovado para a atualização. Se não houver pacote disponível, documente a exposição e o risco residual: exceção explícita é melhor que falsa garantia.

Fonte

[2] Fonte: The Hacker News