한국어

Mitigação temporária para CVE-2026-98432

Este repositório contém scripts que descartam pacotes TCP IPv4 que carregam opções IP em um host Linux. Em hosts sem rotulagem CIPSO do SELinux/Smack NetLabel, a CVE-2026-98432 (um use-after-free no TCP IPv4 do kernel Linux) não pode ser acionada sem tais pacotes. Trata-se de uma mitigação temporária, não de uma correção. Não foi testada contra um exploit real (não há PoC público), e nenhum fornecedor a endossa. Se a sua distribuição já fornece um kernel corrigido, instale-o, e execute revert.sh se você aplicou esta mitigação. Caso contrário, verifique se a mitigação se aplica ao seu host e, em seguida, aplique-a e verifique-a com os passos abaixo (cerca de 10 minutos). O autor é um administrador individual, não um fornecedor.

Isto se aplica a você

1. Compare uname -r com as versões estáveis corrigidas: 5.10.272, 5.15.223, 6.1.190, 6.6.159, 6.12.113, 6.18.56, 7.2.10, 7.3 (commit de correção e3f33b0a1d89d738e2b913dab519226eaf76e15b). Um kernel de distribuição pode conter a correção sob um número de versão diferente, portanto verifique também o rastreador do seu fornecedor.
2. Verifique a rotulagem CIPSO: cat /sys/kernel/security/lsm. Se SELinux ou Smack estiver listado e você usar NetLabel com um mapeamento CIPSOV4, esta mitigação não cobre esse caminho.
3. Verifique os requisitos: root, systemd e nft. O OpenWrt tem seu próprio caminho (veja Arquivos). Hosts sem systemd, exceto OpenWrt, não são cobertos.

Severidade: o CNA do kernel atribui CVSS 9.8. Red Hat, Oracle e SUSE atribuem 8.1, e a Amazon atribui 7.0. A Anthropic descreveu publicamente um exploit remoto de root contra servidores Linux com um listener MPTCP (2026-10-27). Nenhuma exploração in-the-wild foi relatada até 2026-10-29.

Status das distribuições em 2026-10-29/30 (um instantâneo, portanto verifique seu fornecedor):

Distribuição	Status
Ubuntu (todas as versões suportadas)	sem kernel corrigido
RHEL 8/9/10	sem kernel corrigido
Proxmox VE	o changelog do pve-kernel não tinha entrada para esta CVE em 2026-10-30
Debian, Oracle Linux UEK, algumas SUSE, algumas Amazon Linux	correções disponíveis

Aplicar

1. Execute sudo ./mitigate.sh. É idempotente (executá-lo novamente recarrega o conjunto de regras). Ele instala os arquivos listados em Arquivos e encerra se você não for root, se nft estiver ausente ou se systemd estiver ausente.

2. Compare a saída com a referência abaixo. A primeira linha deve ser:

   svc=active enabled=enabled mptcp=0
   

   As duas regras seguem-no, uma na tabela inet e outra na tabela bridge.

3. Se um serviço escutar com MPTCP, reinicie-o. net.mptcp.enabled=0 afeta apenas novos sockets, pelo que um listener MPTCP já aberto permanece MPTCP até o seu serviço ser reiniciado. O sysctl é por network namespace, e o mitigate.sh define-o apenas para o namespace do host.

4. Se o host executar contentores LXC ou Docker, continue com Contentores.

O exploit publicado visava listeners MPTCP. A race em si não requer MPTCP (inferência a partir da descrição da correção). Não está estabelecido se um host sem MPTCP pode ser totalmente comprometido.

Verificar

O SYN-ACK do alvo ecoa as opções IP. Um cliente que ele próprio execute esta mitigação descarta esse SYN-ACK, pelo que o check-blocked.py reporta "blocked" mesmo quando o alvo não está mitigado. Medido num host: após revert.sh no alvo, o check-blocked.py a partir de um cliente mitigado continuou a imprimir ipopt FAIL TimeoutError, enquanto o verify-synack.sh mostrou ipopt synack=5.

Escolha uma ferramenta:

1. Se tiver um cliente sem esta mitigação, execute lá python3 check-blocked.py <host> <port> (não requer root). Liga-se duas vezes: em modo simples e depois com uma opção IPv4 Record Route definida através da opção de socket IP_OPTIONS.
2. Se não puder garantir isso, execute sudo ./verify-synack.sh <ip> <port> em qualquer cliente (é necessário root, tcpdump e python3 no cliente). Envia um SYN simples e um SYN com opções IP a partir de portas de origem fixas e conta os SYN-ACKs do alvo com tcpdump.

Depois compare a saída com a tabela dessa ferramenta.

check-blocked.py (a partir de um cliente sem a mitigação):

Saída	Significado
plain CONNECTED	o TCP normal funciona
ipopt FAIL TimeoutError	o SYN com opções IP foi descartado, como pretendido

verify-synack.sh:

Saída	Significado
plain: CONNECTED synack=N | ipopt: TimeoutError synack=0	o alvo está mitigado
ipopt ... synack>=1	o alvo não está mitigado (o SYN com opções IP foi respondido)

Resultado ao nível do kernel (um host Proxmox VE, kernel 7.0, 2026-10-30): com a mitigação desligada, o caminho de código vulnerável foi executado uma vez por caminho, sobre WireGuard e de LXC para LXC. Com a mitigação ligada, o SYN expirou e o caminho foi executado 0 vezes. A amostra é de 2 caminhos em 2 estados num host. O método de tracing está em docs/ANALYSIS.md (em inglês).

Contentores

O estado do nftables é por network namespace, pelo que as regras do host por si só não protegem os namespaces dos contentores. Medido em contentores LXC: apenas com regras do host, um SYN com opções IP a partir de dentro de um contentor para o seu próprio 127.0.0.1 ou para o seu próprio IP ligava-se. Os contentores partilham o kernel do host, pelo que código dentro de qualquer contentor podia alcançar o caminho vulnerável desta forma.

1. Conclua primeiro o Apply no host.
2. Execute sudo ./inject-netns.sh no host. Carrega o mesmo ruleset em todos os contentores LXC em execução (via pct/lxc-info, Proxmox) e em todos os contentores Docker em execução (os contentores em host-network são ignorados).
3. Compare a saída com a tabela.

Saída	Significado
ok lxc:<id> ou ok docker:<id>	ruleset carregado nesse namespace de contentor
injected=N failed=M	totais, M deve ser 0

A injeção não é persistente. É perdida quando um contentor é reiniciado, pelo que deve voltar a executar o script após reinícios. Os contentores Docker aninhados dentro de um contentor LXC requerem que o script seja executado dentro desse contentor LXC (não medido).

Resultado medido: em 5 hosts Proxmox, 64 namespaces de contentores foram injetados com 0 falhas. Após a injeção, o mesmo teste expirou e o contador de descartes do namespace do contentor aumentou.

Se algo quebrar

O sintoma de esta mitigação interferir é uma ligação TCP que fica pendurada (expira) em vez de ser recusada, juntamente com um contador crescente na saída de:

nft list ruleset | grep counter

Comando	Efeito
systemctl stop cve-2026-98432-mitigation	desliga imediatamente, volta a ligar no reboot
systemctl disable --now cve-2026-98432-mitigation	desliga agora e entre reboots

Compatibilidade medida nos hosts testados: as regras ficam nas suas próprias tabelas e coexistiram com Docker, ufw, regras NAT do iptables-legacy e encaminhamento do NetBird (WireGuard). As ligações TCP normais continuaram a funcionar em todos os caminhos testados. Os contadores de drop mantiveram-se nos valores dos pacotes de teste durante o funcionamento normal (nenhum tráfego legítimo correspondeu) ao longo de uma janela de observação curta (horas, não dias).

Inferência, não medida: um nftables.service cuja configuração contenha flush ruleset apagaria as tabelas quando recarregasse. Verifique isso e volte a executar mitigate.sh após esse recarregamento.

Remover após a aplicação da correção

1. Arranque com o kernel corrigido e confirme com uname -r.
2. Execute sudo ./revert.sh. Adicione --mptcp se também quiser reativar o MPTCP.
3. Compare a última linha da saída: