linux-tcp-uaf-cve-2026-98432

Um kit de resposta para a CVE-2026-98432, uma falha de segurança de memória no código que o kernel Linux usa para estabelecer conexões TCP. Ele contém três coisas:

• Script de diagnóstico — informa se um servidor é vulnerável e qual a urgência. Não faz nenhuma alteração no sistema.
• Mitigações temporárias — uma regra de firewall (usando o iptables instalado por padrão, ou nftables onde o iptables estiver ausente), arquivos de configuração do kernel (sysctl) e playbooks Ansible, todos aplicados sem reinicialização. O modo padrão apenas conta pacotes.
• Guia de resposta — como o bug funciona, status de correção por distribuição, como verificar e os trade-offs de cada mitigação → cve-2026-98432-guide.en.md

🇰🇷 한국어

Escrito em 2026-11-03. Toda mitigação aqui é temporária e não substitui a correção do kernel. Agende a atualização do kernel e a reinicialização (ou um livepatch) separadamente.

	README	Guia	Script de diagnóstico
🇺🇸 Inglês (padrão)	README.md	cve-2026-98432-guide.en.md	check_cve_2026_98432.sh
🇰🇷 한국어	README.ko.md	cve-2026-98432-guide.ko.md	check_cve_2026_98432_ko.sh

---

Em resumo

• Qualquer pessoa na rede pode derrubar o servidor apenas enviando requisições de conexão TCP — sem necessidade de login — e, sob certas condições, foi relatada a tomada de controle remoto como root.
• Quase todo servidor executando Linux 4.4 ou posterior é afetado. Conexões IPv6 não são afetadas.
• A correção real é um kernel corrigido mais uma reinicialização. RHEL, Debian, Amazon Linux e outros já lançaram kernels corrigidos; o Ubuntu ainda está preparando os seus (veja 2. Onde as coisas estão).
• Até você conseguir corrigir, uma regra de firewall que descarta pacotes TCP que carregam opções IPv4 é o controle temporário mais eficaz. Ela usa o iptables instalado por padrão e não requer reinicialização. Por segurança, ela começa apenas contando; mude para descarte depois de confirmar que nenhum tráfego legítimo é afetado.

---

1. O que é este bug?

O cabeçalho IP de uma requisição de conexão TCP pode — raramente — carregar campos extras chamados opções IPv4. O kernel mantém essas opções na memória enquanto a conexão está sendo estabelecida. Ao fazer a limpeza, ele liberava essa memória imediatamente, mesmo que outro núcleo de CPU ainda pudesse estar lendo-a.

Usar memória depois de ela ter sido liberada é chamado de use-after-free (UAF). Se algo mais tiver sido colocado ali nesse meio-tempo, o kernel lê os dados errados, o que pode levar a:

• Uma queda do servidor (kernel panic, DoS) — possível com nada mais do que um serviço TCP comum aberto.
• Execução remota de código como root — em 2026-10-27, a Frontier Red Team da Anthropic disse ter construído um exploit que executa comandos root sem autenticação em servidores com um listener MPTCP (veja o glossário abaixo). Vazar um endereço do kernel levou cerca de 48 minutos, e executar comandos cerca de 5 a mais. O código não foi divulgado.

Item	Detalhe
Afetados	Linux 4.4 e posterior, antes da versão corrigida de cada branch. IPv6 não é afetado
Severidade	CVSS 9.8 (Crítica) pelo Kernel CNA, Red Hat e Ubuntu. SUSE, Amazon e Oracle classificam como 8.1, porque vencer a corrida de timing entre CPUs é difícil
Causa raiz	A memória foi liberada sem esperar o período de liberação segura do kernel (RCU grace period). Correção upstream: commit e3f33b0a1d89 (kfree → kfree_rcu)
Versões de kernel corrigidas	5.10.272, 5.15.223, 6.1.190, 6.6.159, 6.12.113, 6.18.56, 7.2.10, 7.3 ou posterior — para kernels de distribuição, verifique se a correção está incluída, não o número da versão

---

2. Onde as coisas estão

Exploração: em 2026-11-03 não está no CISA KEV (o catálogo de vulnerabilidades conhecidas por serem exploradas), e nenhum ataque no mundo real foi reportado. Muitos repositórios no GitHub afirmam ser "PoCs"; nenhum é verificado — não os execute em redes de produção.

Kernels corrigidos por distribuição (versões e fontes no guia §2.2)

Distribuição	Status
RHEL 8 / 9 / 10	✅ Kernels corrigidos lançados em 2026-11-01 (RHSA-2026:93414 / 93412 / 93413). Nós do OpenShift (RHCOS) ainda não estão corrigidos
Debian 12 / 13	✅ Corrigido (DSA-6568-1, DLA-4841-1, DLA-4850-1)
Amazon Linux 2 / 2023	✅ Corrigido. AMIs otimizadas para EKS/ECS, Fargate e Bottlerocket estão sendo implementadas gradualmente
Rocky Linux (CIQ RLC Pro / LTS)	✅ Todas as variantes suportadas pela CIQ corrigidas. Para o Rocky da comunidade, verifique o Rocky Errata
Ubuntu 22.04 / 24.04 / 26.04 / 26.10	⏳ Em andamento ("work in progress" em 2026-11-03)
Ubuntu 16.04 / 18.04 / 20.04	⏳ O suporte padrão terminou — correções esperadas apenas para assinantes do Ubuntu Pro (ESM)
SUSE, Oracle Linux, AlmaLinux, …	Correções reportadas — verifique o aviso de cada fornecedor

---

3. Meu servidor está em risco?

O script de diagnóstico em 4. O que fazer agora fornece o veredito exato. Como orientação geral:

Para um ataque funcionar, ① o servidor precisa de pelo menos dois núcleos de CPU (dois núcleos devem acessar a mesma memória no mesmo momento), e ② o pacote do atacante deve chegar ao servidor com suas opções IPv4 intactas.

#	Se o servidor estiver…	Risco	O que fazer
1	Em uma VPC interna ou nó Kubernetes, multi-core, com um listener MPTCP (inclusive em contêineres)	🔴 Root remoto	Aplique a regra de firewall e o sysctl agora, e corrija os kernels dos nós. Algumas redes Kubernetes (CNIs baseadas em eBPF) contornam o firewall do host, então a correção vem primeiro
2	Em um IP público ou atrás de um balanceador de carga L4 (AWS NLB, …) com um listener MPTCP	🔴 Root remoto	Aplique a regra de firewall e o sysctl agora
3	Multi-core com apenas serviços TCP comuns	🟠 Crash remoto	Aplique a regra de firewall (o sysctl sozinho não ajuda)
4	CPU única (um vCPU)	🟡 Muito improvável de ter sucesso	Inclua no ciclo regular de correções
5	Acessível apenas através de um proxy L7 (AWS ALB, CloudFront, Cloudflare, …) com acesso interno controlado	🟡 Pacotes de ataque nunca chegam	Corrija para se defender de atacantes internos

⚠️ Não conclua "sem listener MPTCP, então estamos seguros." A Red Hat afirma que verificar listeners MPTCP é "informativo e não uma garantia." Sem MPTCP um crash ainda é possível, e outro método de exploração que não precise de MPTCP não pode ser descartado. Além disso, em kernels da família RHEL 8, ss -M pode mostrar listeners MPTCP como TCP comum.