Uma falha crítica no kernel Linux, identificada como CVE-2026-98432, colocou administradores de servidores e equipes de segurança em alerta. Com pontuação CVSS 9.8, a vulnerabilidade permite que um invasor remoto, sem autenticação ou privilégios prévios, explore uma condição de corrupção de memória no processamento de conexões TCP IPv4. Dependendo das condições de exploração, o problema pode provocar indisponibilidade do sistema ou permitir a execução remota de código com privilégios de root.
O problema merece atenção especial porque está presente desde o Linux 4.4, lançado em 2016, e envolve uma parte fundamental da infraestrutura de rede do sistema operacional. A falha foi corrigida no desenvolvimento do kernel, mas a distribuição dos patches depende dos ciclos de manutenção e validação de cada fornecedor. Red Hat, Ubuntu, Debian, SUSE e Amazon Linux possuem situações distintas de disponibilização das correções.
Neste artigo, vamos explicar como funciona o problema de use-after-free, por que a exploração representa um risco para servidores expostos à internet, quais são as medidas adotadas pelas principais distribuições e como verificar e atualizar os sistemas afetados.
Como funciona a falha crítica no kernel Linux CVE-2026-98432
A CVE-2026-98432 está relacionada ao gerenciamento de memória no subsistema de rede IPv4, especificamente durante o estabelecimento de conexões TCP. O problema envolve uma condição de concorrência, conhecida como race condition, que permite que uma região de memória seja liberada enquanto outro processamento ainda tenta acessar seus dados.
O resultado é uma vulnerabilidade do tipo use-after-free (UAF). Essa categoria de falha ocorre quando um programa continua utilizando um ponteiro que aponta para uma área de memória já liberada. No kernel, esse comportamento é particularmente perigoso porque o código vulnerável opera com privilégios elevados e pode comprometer a estabilidade e a segurança de todo o sistema.
A gravidade está na possibilidade de exploração pela rede. O invasor não precisa necessariamente obter uma conta no servidor, executar um programa local ou convencer um usuário a abrir um arquivo. O caminho de ataque envolve o envio de pacotes TCP IPv4 especialmente construídos para alcançar o processamento vulnerável.
A mecânica do use-after-free na pilha de rede
Para compreender a vulnerabilidade, é necessário observar o funcionamento do estabelecimento de conexões TCP.
Quando um cliente inicia uma conexão, envia um pacote SYN ao servidor. O kernel cria uma estrutura temporária, chamada request socket, para acompanhar o processo de conexão. Nesse momento, determinadas opções presentes no cabeçalho IPv4 podem ser armazenadas e utilizadas posteriormente durante a comunicação.
Entre essas opções estão Timestamp e Record Route, recursos opcionais do protocolo IP que permitem registrar informações relacionadas ao processamento e ao percurso dos pacotes.
O problema acontece durante o tratamento de solicitações retransmitidas. Quando o cliente retransmite um SYN, outra CPU pode processar a solicitação simultaneamente à conclusão do estabelecimento da conexão original.
O código responsável por criar o socket definitivo, na função tcp_v4_syn_recv_sock(), transfere a propriedade de ireq->ireq_opt para newinet->inet_opt sem produzir uma cópia independente dos dados.
Isso significa que duas operações podem acabar dependendo da mesma região de memória.
Enquanto uma CPU ainda utiliza as opções IP para construir uma resposta SYN-ACK, outra pode concluir o processamento, encerrar o socket filho e liberar a memória correspondente.
A situação se torna perigosa porque funções como tcp_v4_send_synack() e inet_csk_route_req() acessam essas opções sob proteção de RCU (Read-Copy-Update). Entretanto, a liberação original utilizava kfree(), que não respeitava o período de espera necessário para garantir que todos os leitores tivessem terminado.
Consequentemente, ip_options_build() pode acessar informações que já foram liberadas. O mesmo problema de gerenciamento de memória também foi identificado no caminho de migração de solicitações TCP, envolvendo tcp_v4_reqsk_destructor().
A correção utiliza kfree_rcu(), mecanismo que posterga a liberação da memória até que os leitores protegidos por RCU tenham concluído suas operações.
É importante observar que a vulnerabilidade descrita na primeira condição de exploração está relacionada ao IPv4. O caminho equivalente do IPv6 não apresenta o mesmo problema de transferência de opções, embora exista uma questão separada relacionada à migração de solicitações.
Exploração remota e o papel da inteligência artificial
A preocupação aumentou depois que a Anthropic divulgou detalhes sobre a descoberta e exploração da vulnerabilidade por meio de seus modelos de inteligência artificial.
Em 27 de outubro de 2026, a empresa relatou a construção de uma exploração capaz de obter execução de comandos como root em servidores Linux vulneráveis que disponibilizam conexões Multipath TCP (MPTCP).
A técnica descrita envolve aproveitar a condição de corrida para obter informações da memória do kernel, contornar mecanismos de proteção como KASLR (Kernel Address Space Layout Randomization) e manipular estruturas utilizadas pelo sistema.
O MPTCP permite estabelecer conexões TCP utilizando múltiplos caminhos de rede. Embora tenha sido utilizado na demonstração de exploração, ele não é um requisito para a existência da vulnerabilidade original.
Também é necessário diferenciar a existência de uma prova de conceito de uma exploração completa. Há demonstrações públicas que reproduzem a condição de use-after-free e permitem observar o comportamento vulnerável, mas isso não significa que todos os servidores possam ser comprometidos automaticamente.
Até as informações divulgadas no início de novembro, a Anthropic havia relatado a exploração funcional, mas não disponibilizado publicamente seu exploit completo de execução remota como root.
A possibilidade de automatizar partes desse processo com inteligência artificial reforça a necessidade de reduzir a exposição dos serviços e instalar as correções sem atrasos desnecessários.
Status das correções: Red Hat, Ubuntu, Debian, SUSE e Amazon Linux
A distribuição das correções para a CVE-2026-98432 demonstra como os fornecedores de Linux adotam estratégias diferentes para lidar com vulnerabilidades críticas no kernel. Enquanto algumas distribuições já disponibilizaram pacotes corrigidos, outras continuam realizando testes de compatibilidade antes de liberar as atualizações para todos os usuários.
Essa diferença é especialmente importante em ambientes corporativos, nos quais uma atualização de kernel pode afetar aplicações, módulos externos, drivers, hipervisores e serviços que dependem de configurações específicas.
Red Hat acelera correções para RHEL 8, 9 e 10
A Red Hat classificou o problema como crítico e publicou o boletim RHSB-2026-016, identificando o impacto sobre:
- Red Hat Enterprise Linux 8;
- Red Hat Enterprise Linux 9;
- Red Hat Enterprise Linux 10;
- Red Hat OpenShift Container Platform.
A empresa informou que está acelerando a disponibilização das correções. Entretanto, é importante diferenciar a publicação do alerta de segurança da efetiva disponibilização de um pacote corrigido para cada versão do produto.
Na atualização do boletim em 2 de novembro de 2026, a Red Hat apresentava orientações de mitigação e recomendava instalar as atualizações de kernel assim que fossem liberadas. Portanto, administradores não devem presumir que todos os sistemas RHEL 8, 9 e 10 já estejam protegidos apenas porque o comunicado foi publicado.
Para verificar a disponibilidade de atualizações:
sudo dnf check-update kernelQuando o pacote corrigido estiver disponível nos repositórios habilitados, a atualização pode ser realizada com:
sudo dnf update kernelDepois da instalação, programe uma reinicialização para carregar o novo kernel.
Ubuntu mantém os pacotes em validação no canal -proposed
A estratégia da Canonical, responsável pelo Ubuntu, é diferente. Em comunicado publicado em 2 de novembro, a empresa informou que as correções para Ubuntu 22.04 LTS e versões posteriores estavam disponíveis no repositório -proposed, utilizado para validar atualizações antes de sua distribuição geral.
A Canonical explicou que realiza testes em mais de 2.000 servidores e dispositivos certificados para reduzir o risco de regressões e incompatibilidades.
A situação informada para as versões do Ubuntu era:
Os pacotes em validação incluem as versões 5.15.0-203.213, 6.8.0-149.149 e 7.0.0-43.43, respectivamente para Ubuntu 22.04, 24.04 e 26.04.
A decisão de manter os pacotes em testes está relacionada à estabilidade de uma ampla variedade de equipamentos e configurações. O canal -proposed não é destinado à atualização indiscriminada de servidores de produção.
Administradores que possuem infraestrutura própria de testes podem habilitar esse repositório e instalar os pacotes antecipadamente, seguindo as instruções da Canonical. Entretanto, ambientes críticos devem avaliar cuidadosamente as consequências de utilizar pacotes ainda em qualificação.
Para consultar o kernel em execução:
uname -rPara verificar os pacotes de kernel instalados:
dpkg -l 'linux-image*' | grep ^iiO comando uname -r apresenta apenas o kernel atualmente carregado. Portanto, a existência de um pacote corrigido instalado não significa necessariamente que o servidor já esteja executando essa versão. A reinicialização continua sendo necessária.
Debian, SUSE e Amazon Linux também disponibilizam correções
O Debian apresenta pacotes corrigidos para diferentes versões. No rastreador de segurança, o Debian 12 Bookworm aparece corrigido a partir do pacote 6.1.190-1, enquanto o Debian 13 Trixie recebe a correção a partir de 6.12.113-1. Versões mais recentes também apresentam pacotes corrigidos.
No ecossistema SUSE, a situação varia conforme o produto e seu ciclo de suporte. A empresa já relaciona pacotes corrigidos, incluindo o kernel 6.12.0-160000.40.1 para determinados produtos, enquanto outras versões continuam em andamento.
O Amazon Linux 2 e o Amazon Linux 2023 também possuem pacotes de kernel corrigidos. A AWS recomenda instalar as atualizações correspondentes à versão utilizada e reiniciar as instâncias.
Para Amazon Linux 2:
sudo yum update kernel sudo rebootPara Amazon Linux 2023:
sudo dnf update kernel sudo rebootEm todos esses casos, é fundamental consultar o boletim específico da distribuição. Os números de versão não podem ser comparados indiscriminadamente entre fornecedores, pois distribuições corporativas frequentemente aplicam correções por meio de backports, mantendo a numeração original de seus pacotes.
Mitigação da falha crítica no kernel Linux com nftables
Enquanto a atualização definitiva não estiver disponível, administradores podem reduzir a exposição utilizando regras de filtragem de pacotes.
A própria Red Hat publicou uma regra baseada em nftables que bloqueia pacotes TCP IPv4 contendo opções adicionais no cabeçalho IP.
A configuração utiliza a expressão ip hdrlength > 5, que identifica cabeçalhos IPv4 maiores que o tamanho mínimo de 20 bytes.
Crie um arquivo chamado cve-2026-98432.nft com o seguinte conteúdo:
table inet cve_2026_98432 { chain input { type filter hook input priority -310; policy accept; ip protocol tcp ip hdrlength > 5 counter drop } }Antes de aplicar a regra, valide a configuração:
sudo nft --check --file cve-2026-98432.nftSe não houver erros, aplique-a:
sudo nft --file cve-2026-98432.nftConfira se a tabela foi carregada:
sudo nft list table inet cve_2026_98432A filtragem procura impedir que pacotes com opções IPv4 alcancem o processamento vulnerável. O tráfego TCP convencional, cujas opções são transportadas no cabeçalho TCP, não é o alvo dessa regra.
Entretanto, essa abordagem possui limitações importantes.
Primeiro, ela não corrige o defeito de gerenciamento de memória. Apenas reduz a exposição a determinados pacotes que podem acionar o caminho vulnerável.
Segundo, a regra aplicada na cadeia input não cobre automaticamente todo o tráfego que circula internamente entre contêineres ou atravessa diferentes namespaces de rede. Ambientes Kubernetes e OpenShift precisam considerar suas arquiteturas de rede antes de aplicar qualquer filtragem.
Além disso, aplicações que dependem de opções IPv4 específicas podem apresentar problemas de conectividade. Por isso, a Red Hat recomenda testar a configuração em um ambiente controlado antes de utilizá-la em produção.
Após instalar o kernel corrigido e confirmar que o sistema está executando a nova versão, a regra temporária pode ser removida:
sudo nft delete table inet cve_2026_98432A filtragem deve ser tratada como uma medida provisória, nunca como substituta da atualização de segurança.
Conclusão: atualização do kernel deve ser prioridade para administradores Linux
A CVE-2026-98432 demonstra como um problema aparentemente específico no gerenciamento de memória pode representar uma ameaça significativa para toda a infraestrutura de um servidor Linux.
A combinação de execução remota sem autenticação, corrupção de memória e possibilidade de obtenção de privilégios de root torna essa vulnerabilidade especialmente relevante para ambientes expostos à internet.
O histórico da falha, presente desde o Linux 4.4, também mostra a importância de manter inventários atualizados e acompanhar os boletins de segurança das distribuições utilizadas.
Administradores devem identificar os sistemas potencialmente afetados, verificar a disponibilidade dos pacotes corrigidos, testar as atualizações e programar janelas de manutenção para instalação e reinicialização.
Em infraestruturas que ainda não podem receber o patch, regras de firewall podem ajudar a reduzir a exposição, desde que suas limitações sejam compreendidas.
Outro ponto importante é não confundir a ausência de um exploit público com a ausência de risco. A demonstração de exploração relatada pela Anthropic mostra que técnicas avançadas de exploração de vulnerabilidades no kernel podem ser desenvolvidas com auxílio de inteligência artificial.