Falha no kernel Linux dá root remoto: como se proteger

Uma falha no kernel Linux, a CVE-2026-98432, atinge o código que abre conexões TCP sobre IPv4. Um pacote de abertura de conexão (SYN) com opções IPv4 consegue acionar um use-after-free: o kernel acaba lendo memória que já foi liberada. A falha existe desde o kernel 4.4, não exige login e recebeu nota CVSS 9.8 da equipe de CVE do kernel (NVD).

Pesquisadores publicaram a demonstração de um exploit que dá root remoto, sem senha, num servidor com um listener MPTCP (relato da demonstração). A correção já saiu no kernel oficial e no Debian, mas Ubuntu e RHEL ainda não publicaram kernel corrigido (situação na manhã de 31/10/2026). Se você cuida de servidor Linux, veja abaixo como saber se está afetado, como atualizar por distro, o que fazer enquanto o patch não chega e o que conferir depois.

O que é a CVE-2026-98432

Segundo o registro oficial da CVE no kernel.org, quando uma conexão TCP IPv4 termina o aperto de mão, a função tcp_v4_syn_recv_sock() passa as opções IP guardadas no pedido de conexão pro socket novo sem copiá-las. Ao mesmo tempo, outro núcleo da CPU pode estar processando um SYN retransmitido do mesmo pedido e montando o SYN-ACK com essas mesmas opções. Se o socket novo for destruído nesse meio-tempo, as opções são liberadas com um kfree() comum enquanto ainda estão em uso, e o kernel lê memória liberada em ip_options_build().

O mesmo problema aparece na migração de pedidos de conexão entre sockets (com net.ipv4.tcp_migrate_req=1 ou um programa BPF do tipo BPF_SK_REUSEPORT_SELECT_OR_MIGRATE). A correção troca kfree() por kfree_rcu() em inet_sock_destruct() e tcp_v4_reqsk_destructor(), ou seja, a memória só é liberada depois que ninguém mais está lendo. O IPv6 não é afetado pelo primeiro problema, porque copia as opções.

Por que a demonstração assusta

No relato publicado, o exploit funciona em duas etapas contra um servidor com listener MPTCP: primeiro usa a corrida pra fazer o kernel devolver bytes extras e vazar um endereço do kernel, o que derruba a proteção KASLR; depois usa a mesma falha pra sobrescrever um ponteiro e executar um comando como root. Uma tentativa que perde a corrida só faz o aperto de mão falhar, sem derrubar o sistema, então o atacante pode repetir até acertar. Na prova de conceito, foram 48 minutos pra vazar o endereço e mais cerca de 5 minutos pra chegar à execução de comando.

As notas variam, mas o risco é real

A equipe de CVE do kernel deu 9.8 (ataque pela rede, complexidade baixa, sem privilégios). Ubuntu classifica com prioridade Alta, e a Red Hat classifica como Crítica no dado oficial atual (dados da Red Hat), embora outras distribuições tenham dado notas mais baixas por considerarem a corrida difícil de ganhar. Até agora não há exploração conhecida em ataques reais, e a falha não aparece no catálogo KEV da CISA (versão de 30/10/2026).

Estou afetado?

Praticamente todo servidor Linux com kernel 4.4 ou mais novo que ainda não recebeu a correção está no grupo afetado. Comece descobrindo o kernel que está rodando (não o que está instalado):

uname -r

Versões oficiais do kernel que já trazem a correção, por ramo:

• 5.10.272, 5.15.223, 6.1.190, 6.6.159, 6.12.113, 6.18.56, 7.2.10 e 7.3 ou mais novo.

Kernel de distribuição recebe correções por backport, então o número sozinho não diz tudo. Compare com o aviso da sua distro:

DistribuiçãoSituação (31/10/2026, manhã)FonteDebian 12 (bookworm)Corrigido em linux 6.1.190-1 (DLA-4841-1) e linux-6.12 6.12.113-1~deb12u1 (DLA-4850-1)DebianDebian 13 (trixie)Corrigido em linux 6.12.113-1 (DSA-6568-1)DebianUbuntu 22.04, 24.04, 26.04 e 26.10Vulnerável, correção "em andamento"UbuntuUbuntu 16.04, 18.04 e 20.04VulnerávelUbuntuRHEL 8, 9 e 10, OpenShift 4Afetado, sem correção publicada (RHEL 6 e 7: não afetados)Red HatRocky Linux 8, 9 e 10Sem kernel corrigido em 30/10; acompanhe as erratas do RockyCIQAmazon Linux 2023Corrigido nos pacotes kernel6.18 (6.18.56-125.164) e kernel6.12 (6.12.113-138.209); pacote kernel padrão e Amazon Linux 2 ainda pendentesThe Hacker News

Oracle Linux (kernel UEK) e algumas versões do SUSE/openSUSE também já têm pacotes corrigidos; confira o aviso do fornecedor pro seu kernel exato.

MPTCP e serviços escritos em Go

O ataque demonstrado precisa de um listener MPTCP (Multipath TCP), mas o próprio time de segurança do Go avisa que o bug não é específico do MPTCP e que sistemas sem MPTCP podem ser vulneráveis a ataques parecidos. Vale saber se você tem MPTCP ativo, porque programas em Go 1.24 ou mais novo ativam MPTCP por padrão nos sockets de escuta no Linux, quando o kernel permite:

sysctl net.mptcp.enabled
# 1 = listeners podem negociar MPTCP

ss -Mltn
# linhas com Netid "mptcp" indicam listener MPTCP

Em alguns kernels mais antigos (como os da série 4.18 do RHEL 8) o ss -Mltn pode não mostrar a linha mptcp, então o sysctl é a checagem que funciona em todos, segundo a CIQ.

No Go, dá pra desligar o MPTCP por programa com GODEBUG=multipathtcp=0 no ambiente ou godebug multipathtcp=0 no go.mod. O próprio time do Go chama isso de proteção frágil: um único listener esquecido continua exposto, e nada garante que todo exploit dependa de MPTCP.

Como corrigir: atualize o kernel e reinicie

A correção de verdade é rodar um kernel corrigido. Instalar o pacote não basta: o kernel novo só entra em ação depois do reboot. Antes de mexer em produção, tenha backup e um plano de volta (veja o nosso guia de como atualizar o sistema com backup).

Debian e Ubuntu

sudo apt update
sudo apt full-upgrade
sudo reboot

# depois do reboot
uname -r

No Debian a correção já está disponível pelo repositório de segurança. No Ubuntu, rode o mesmo comando assim que o kernel corrigido for publicado e acompanhe a página da CVE no Ubuntu.

RHEL, Rocky, Alma, Oracle e Amazon Linux

sudo dnf update 'kernel*'
sudo reboot

# depois do reboot
uname -r

Nas distros baseadas em RPM, dá pra conferir se o changelog do kernel em execução cita a CVE. Rode também a linha de controle: ela precisa dar mais que 0, senão a checagem não prova nada:

rpm -q --changelog kernel-core-$(uname -r) | grep -c CVE-2026-98432
rpm -q --changelog kernel-core-$(uname -r) | grep -c CVE-20

Docker e Kubernetes: a imagem não corrige o kernel

Containers usam o kernel do host. Trocar a imagem, rebuildar ou atualizar o sistema dentro do container não resolve nada aqui: é preciso atualizar e reiniciar o host (ou cada nó do cluster). Se você está começando com containers, o post Docker no servidor: primeiro passo explica essa relação entre host e container.

Em Kubernetes, faça um nó por vez pra não derrubar a aplicação:

kubectl drain NOME_DO_NO --ignore-daemonsets --delete-emptydir-data
# no nó: atualize o kernel e reinicie
kubectl uncordon NOME_DO_NO

Em serviços gerenciados (EKS, GKE, AKS e afins), atualize os grupos de nós pra uma imagem com o kernel corrigido assim que o provedor publicar.

Sem correção ainda? Mitigação temporária

Pra quem está em Ubuntu, RHEL ou Rocky e não pode esperar, a CIQ publicou e testou uma regra de nftables que descarta todo pacote TCP IPv4 com cabeçalho maior que 20 bytes, ou seja, exatamente os que trazem opções IP, antes de o TCP processá-los. O objeto vulnerável só é criado quando o SYN (ou o ACK de syncookie) carrega opções IP, então isso fecha o caminho conhecido.

Atenção: a regra muda o firewall em produção e também derruba tráfego TCP legítimo que use opções IP. Teste primeiro num servidor fora de produção. Use aspas duplas retas na linha da chain, exatamente como abaixo.

Regra temporária (vale até o próximo reboot)

sudo nft add table inet ciq_cve_2026_98432
sudo nft add chain inet ciq_cve_2026_98432 prerouting "{ type filter hook prerouting priority -300; policy accept; }"
sudo nft add rule inet ciq_cve_2026_98432 prerouting ip hdrlength gt 5 meta l4proto tcp counter drop

# conferir
sudo nft list table inet ciq_cve_2026_98432

A regra fica numa tabela própria, então firewall-cmd --reload e systemctl restart firewalld não a removem. Mas o nftables.service, ao parar, limpa o ruleset inteiro e leva a tabela junto.

Versão persistente (carrega no boot)

A CIQ também publicou uma versão com arquivo próprio e unidade systemd. Salve o bloco num arquivo e rode com bash em vez de colar no terminal:

sudo tee /etc/nftables/ciq-cve-2026-98432.nft >/dev/null <<'EOF'
add table inet ciq_cve_2026_98432
delete table inet ciq_cve_2026_98432
table inet ciq_cve_2026_98432 {
  chain prerouting {
    type filter hook prerouting priority -300; policy accept;
    ip hdrlength gt 5 meta l4proto tcp counter drop
  }
}
EOF
sudo tee /etc/systemd/system/ciq-cve-2026-98432-nft.service >/dev/null <<'EOF'
[Unit]
Description=Drop IPv4 TCP packets that carry IP options (interim mitigation for CVE-2026-98432)
Wants=network-pre.target
Before=network-pre.target

[Service]
Type=oneshot
RemainAfterExit=yes
ExecStart=/usr/sbin/nft -f /etc/nftables/ciq-cve-2026-98432.nft
ExecStop=-/usr/sbin/nft delete table inet ciq_cve_2026_98432

[Install]
WantedBy=multi-user.target
EOF
sudo nft -c -f /etc/nftables/ciq-cve-2026-98432.nft
sudo systemctl daemon-reload
sudo systemctl enable --now ciq-cve-2026-98432-nft.service
systemctl is-active ciq-cve-2026-98432-nft.service

O caminho /etc/nftables/ é o padrão das distros da família RHEL, onde a regra foi testada. Em Debian e Ubuntu a pasta pode não existir: crie antes com sudo mkdir -p /etc/nftables e confira o caminho do nft com command -v nft.

Restrinja o acesso a IPs confiáveis

Enquanto o patch não sai, reduza quem consegue abrir conexão TCP com o servidor: deixe SSH, painéis, bancos e APIs internas acessíveis só por VPN, rede privada ou lista de IPs confiáveis no firewall do servidor ou do provedor de nuvem. Isso não corrige o bug, mas diminui muito quem pode tentar.

Por que desligar o MPTCP não basta

Nos testes da CIQ, com net.mptcp.enabled=0, um listener TCP comum continuou aceitando SYN com a opção Record Route e devolvendo a opção no SYN-ACK em todos os kernels testados, ou seja, o caminho vulnerável segue alcançável. Desligar o MPTCP pode reduzir a exposição ao exploit demonstrado, mas não substitui o patch nem a regra de firewall.

Depois de atualizar: o que conferir

1. Kernel rodando: uname -r mostra a versão corrigida da sua distro? Pacote instalado sem reboot não protege.
2. Changelog (RPM): rode as duas linhas de rpm -q --changelog acima.
3. Todos os servidores: VMs esquecidas, bastions, nós de cluster, máquinas de CI e imagens base de VM usadas pra criar servidores novos.
4. Remova a mitigação só quando o kernel corrigido estiver rodando:

sudo nft delete table inet ciq_cve_2026_98432

# se instalou a versão persistente:
sudo systemctl disable --now ciq-cve-2026-98432-nft.service
sudo rm -f /etc/systemd/system/ciq-cve-2026-98432-nft.service /etc/nftables/ciq-cve-2026-98432.nft
sudo systemctl daemon-reload

1. Se o servidor não voltar depois do reboot com o kernel novo, o post Kernel panic "Unable to mount root fs" ajuda a achar a causa e recuperar o boot.

Já passou por algo parecido este mês? O guia da falha no kernel Linux CVE-2026-46300 segue o mesmo roteiro de checagem e atualização.

Perguntas frequentes

Meu servidor não usa MPTCP. Estou seguro?

Não dá pra contar com isso. A demonstração usou MPTCP, mas o bug está no TCP IPv4 comum e o time do Go diz que sistemas sem MPTCP podem ser vulneráveis a ataques parecidos. Atualize o kernel.

Só uso IPv6. Preciso me preocupar?

O primeiro problema não afeta IPv6, mas quase todo servidor também aceita IPv4. Se a máquina tem qualquer porta TCP aberta em IPv4, ela está no caminho.

Atualizar a imagem Docker resolve?

Não. O kernel é do host. Atualize e reinicie o host ou o nó do cluster.

Já estão explorando?

Até a manhã de 31/10/2026 não havia relato de exploração em ataques reais nem entrada no catálogo KEV da CISA. Como a demonstração é pública, trate como urgente.

A regra de nftables quebra alguma coisa?

Ela descarta tráfego TCP IPv4 com opções IP, que é raro na internet, mas pode existir em redes específicas. Teste antes num servidor fora de produção e remova a regra quando o kernel corrigido estiver rodando.

Resumo

• CVE-2026-98432: use-after-free no TCP IPv4 do kernel Linux, desde o 4.4, sem login, CVSS 9.8.
• Root remoto foi demonstrado em servidor com listener MPTCP; Go 1.24+ ativa MPTCP por padrão.
• Kernels corrigidos: 5.10.272, 5.15.223, 6.1.190, 6.6.159, 6.12.113, 6.18.56, 7.2.10 e 7.3. Debian já corrigiu; Ubuntu e RHEL ainda não.
• Atualize o kernel do host, reinicie e confira com uname -r. Container não resolve.
• Sem patch: regra temporária de nftables + acesso só de IPs confiáveis. Desligar o MPTCP sozinho não basta.

Fontes: registro da CVE no kernel.org, NVD, Ubuntu, Red Hat, Debian, CIQ, anúncio do time de segurança do Go, issue 82717 do Go, relato da demonstração, BleepingComputer e The Hacker News.