CVE-2026-98432: vulnerabilidade TCP no kernel Linux — o que é e o que fazer no seu VPS ou servidor dedicado

A 29 de outubro de 2026, a vulnerabilidade CVE-2026-98432 do kernel Linux está corrigida nos ramos estáveis oficiais e no Debian, mas Ubuntu, Red Hat, AlmaLinux, Rocky e SUSE 15 ainda não publicaram um kernel corrigido. No momento da publicação não se conhece nenhum exploit público. Se tem um VPS ou um servidor dedicado Linux na Fusiora, é o próprio cliente que gere o kernel: neste artigo explicamos o que aconteceu e que passos seguir.

O que aconteceu, em linguagem simples

Quando alguém abre uma ligação TCP ao seu servidor, o kernel guarda temporariamente alguma informação do primeiro pacote (o SYN). Se esse pacote trouxer opções IPv4 (campos opcionais do cabeçalho IP, como Record Route ou Timestamp, que o tráfego normal quase nunca usa), o kernel pode libertar essa memória enquanto outra parte do sistema ainda a está a usar. É o que se chama um use-after-free.

Na prática, o resultado mais provável é o servidor bloquear e reiniciar (negação de serviço). As fontes oficiais não estão de acordo quanto à gravidade: o registo do CVE refere também uma possível divulgação ao atacante de conteúdo da memória do kernel e corrupção de memória, enquanto a Red Hat indica que o mais provável é um bloqueio e que não foi demonstrado impacto na confidencialidade nem na integridade.

Detalhe técnico breve

• Correção: commit e3f33b0a1d89 «ipv4: free inet_opt and ireq_opt after an RCU grace period» (Eric Dumazet, 1 de outubro de 2026), incluído no Linux 7.3. Substitui duas chamadas kfree() por kfree_rcu() em net/ipv4/af_inet.c e net/ipv4/tcp_ipv4.c.
• Causa: tcp_v4_syn_recv_sock() passa ao socket filho as opções IP do pedido sem as copiar. Se, ao mesmo tempo, chegar um SYN retransmitido, outra CPU pode estar a enviar um SYN-ACK com essas opções enquanto o socket filho é destruído e as liberta.
• Segunda variante: apenas com a migração de pedidos TCP ativada (net.ipv4.tcp_migrate_req=1, que por omissão vale 0, ou com um programa BPF de reuseport que migre pedidos).
• Vetor: remoto e sem autenticação, durante o handshake, antes de a aplicação intervir. É necessário um serviço TCP à escuta em IPv4, um SYN com opções IP e ganhar uma condição de corrida (race condition). O CNA considera a complexidade baixa; a Red Hat e a SUSE, alta.
• IPv6: não é afetado pela falha principal. Não é preciso desativar o IPv6.

Quem é afetado?

• VPS Linux: cada VPS arranca o seu próprio kernel, que o cliente instala e atualiza a partir do sistema operativo. Se o seu VPS usa um kernel vulnerável, tem de o atualizar e reiniciar.
• Servidores dedicados Linux: o mesmo. Tem acesso root total e o kernel é da sua responsabilidade.
• Contentores (Docker, LXC, Podman) no seu servidor: partilham o kernel do anfitrião, pelo que ficam protegidos ao atualizar o kernel desse servidor.
• Não afetados: Windows Server e FreeBSD, porque não usam o kernel Linux.

Estado dos patches a 29 de outubro de 2026

Kernels oficiais (kernel.org). Estas versões, ou qualquer versão posterior do mesmo ramo, já incluem a correção:

O registo do CVE não inclui nenhum ramo 4.x nem 5.4 corrigido (ambos sem suporte oficial).

Por distribuição. Atenção: as distribuições numeram os seus kernels à sua maneira, por isso o que conta é o pacote corrigido de cada uma:

Nas distribuições que incluem kernels recentes dos ramos oficiais (por exemplo Fedora, Arch ou Alpine), compare a sua versão com a tabela do kernel.org. Se usa Debian 10 ou 11 ou outro sistema sem suporte, não conte com receber um patch: planeie a migração para uma versão com suporte (num VPS, a partir do painel, Manage → Rebuild; atenção, reinstalar apaga todos os dados; num dedicado, abra um ticket). O CentOS 7 usa o kernel do RHEL 7, que segundo a Red Hat não é afetado por este CVE, mas já não recebe atualizações de segurança: continua a ser aconselhável migrar.

Passos para o cliente

Ligue-se por SSH (guia) e execute os comandos como root ou com sudo.

1. Verifique que kernel está a usar

uname -r

No Debian, a versão exata do pacote aparece no fim de:

uname -v

Por exemplo, «Debian 6.12.113-1» ou superior no Debian 13 significa que já tem a versão corrigida. No Ubuntu, no RHEL e nos seus derivados, o número de uname -r é o da própria distribuição: compare-o com o respetivo aviso, não com a tabela do kernel.org.

2. Faça uma cópia de segurança antes de alterar algo

Se o seu plano inclui snapshots, crie um antes de atualizar. Caso contrário, copie para fora do servidor tudo o que não pode perder. Atualizar o kernel é rotina, mas é no reinício que um problema já existente pode vir à tona.

3. Atualize o sistema

Debian e Ubuntu:

apt update && apt full-upgrade

No Debian 12, se usa o kernel 6.12 do pacote linux-6.12 (DLA-4850-1), o full-upgrade também o atualiza. Para verificar os pacotes de kernel instalados:

dpkg -l 'linux-image*'

AlmaLinux, Rocky, RHEL, Fedora, Oracle e CloudLinux:

dnf upgrade --refresh

rpm -q kernel

SUSE e openSUSE:

zypper refresh && zypper patch

Arch:

pacman -Syu

Alpine:

apk update && apk upgrade

No Ubuntu, RHEL, AlmaLinux e Rocky ainda não existe kernel corrigido a 29 de outubro; no Oracle Linux (kernel UEK) e no CloudLinux, consulte o aviso do seu fornecedor. Mesmo assim vale a pena aplicar as atualizações pendentes, e deve repetir este passo assim que a sua distribuição publicar o respetivo aviso (ver o passo 8); entretanto, aplique a mitigação do passo 5.

4. Reinicie e verifique a nova versão

O novo kernel só é usado depois de reiniciar:

reboot

Quando o servidor voltar, execute de novo uname -r (e uname -v no Debian) e compare o resultado com o pacote corrigido da sua distribuição (tabela «Por distribuição»), ou com a tabela do kernel.org se usa um kernel oficial. Se o servidor não responder por SSH depois do reinício:

• VPS: entre no painel vps.fusiora.com e abra a consola VNC (separador Options → Browser VNC; se não vir o botão, clique primeiro em Enable VNC).
• Servidor dedicado: use a consola remota IPMI/KVM.
• No menu do GRUB (no Debian e no Ubuntu, em «Advanced options»; se o menu não aparecer, mantenha premida a tecla Shift ou prima Esc durante o arranque) pode escolher o kernel anterior enquanto investiga.

5. Se a sua distribuição ainda não tem patch: mitigação temporária

A falha só é desencadeada por SYN TCP IPv4 com opções IP, muito raros no tráfego legítimo. Pode descartar esses pacotes com nftables. A regra deixa passar os SYN normais e não afeta o IPv6 nem outros protocolos. Se o seu servidor encaminha tráfego (por exemplo, como router ou gateway VPN), também filtra esses SYN em trânsito. Não substitui o patch.

Se não tem o comando nft, instale-o com apt install nftables ou dnf install nftables. A regra fica numa tabela própria, que coexiste com ufw, firewalld e Docker:

nft add table inet cve_2026_98432

nft add chain inet cve_2026_98432 pre '{ type filter hook prerouting priority -300; policy accept; }'

nft add rule inet cve_2026_98432 pre 'ip hdrlength > 5 tcp flags & (syn | ack) == syn counter drop'

Para a verificar (o contador mostra quantos pacotes descartou):

nft list table inet cve_2026_98432

Para a remover:

nft delete table inet cve_2026_98432

Adicionada desta forma, a regra não sobrevive a um reinício. Não a adicione a /etc/nftables.conf nem ative o nftables.service para isto: conforme a distribuição, essa configuração apaga todas as regras do sistema, incluindo as do Docker ou do ufw. Se precisar que persista entre reinícios, guarde-a num ficheiro próprio, /etc/cve-2026-98432.nft:

table inet cve_2026_98432 {
  chain pre {
    type filter hook prerouting priority -300; policy accept;
    ip hdrlength > 5 tcp flags & (syn | ack) == syn counter drop
  }
}

E carregue-a com um serviço próprio, /etc/systemd/system/cve-2026-98432.service:

[Unit]
Description=Mitigation CVE-2026-98432

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

[Install]
WantedBy=multi-user.target

Primeiro remova a regra manual, se a adicionou (nft delete table inet cve_2026_98432), para que não fique duplicada. Depois:

systemctl daemon-reload && systemctl enable --now cve-2026-98432.service

Quando estiver no kernel corrigido, desative-a com systemctl disable --now cve-2026-98432.service.

Em sistemas mais antigos sem nftables, o equivalente em iptables é:

iptables -t raw -I PREROUTING -p tcp --syn -m u32 ! --u32 "0>>22&0x3C=20" -j DROP

Tal como a regra nft adicionada à mão, esta também não sobrevive a um reinício.

Verifique também que a variante de migração está desativada (deve devolver 0, o valor por omissão):

sysctl net.ipv4.tcp_migrate_req

Se indicar que a chave não existe, o seu kernel não tem essa funcionalidade e esta variante não se aplica.

Não filtre todos os pacotes com opções IP: o IGMP usa-as e deixaria o multicast sem funcionar. A regra acima está limitada de propósito aos SYN TCP.

6. Livepatch: só onde existe

A 29 de outubro de 2026 não encontrámos nenhum patch em direto (livepatch) para este CVE da Canonical, da Red Hat nem da SUSE. A SUSE publicou um kernel corrigido para a 16.0 (6.12.0-160000.40.1), que exige reinício. Sem patch em direto, a solução é atualizar o kernel e reiniciar.

7. Reveja o que expõe à Internet

A falha precisa de um serviço TCP à escuta em IPv4. É uma boa altura para fechar na firewall (ufw ou firewalld) as portas de que não precisa e limitar as de administração aos seus próprios IP. O nosso guia Configure o seu primeiro VPS cobre a configuração básica da firewall.

8. Acompanhe os avisos e peça ajuda se precisar

Acompanhe a página do CVE da sua distribuição (ligações abaixo) e, quando surgir o kernel corrigido, repita os passos 3 e 4. Se tiver dúvidas ou algo não arrancar depois de atualizar, abra um ticket com o seu serviço e o resultado de uname -r.

Perguntas frequentes

A Fusiora atualiza o kernel do meu VPS ou servidor dedicado?

Não, a não ser que tenha contratado um serviço gerido; nesse caso, confirme com o suporte. Num VPS ou servidor dedicado padrão tem acesso root total e é o próprio cliente que gere o sistema operativo, kernel incluído. Se quiser ajuda com os passos, abra um ticket.

Basta atualizar os pacotes?

Não. Até reiniciar continua a usar o kernel antigo. Confirme com uname -r que está na nova versão.

Tenho de desativar o IPv6?

Não. O IPv6 não é afetado pela falha principal.

A regra de nftables pode estragar alguma coisa?

Só descarta SYN TCP IPv4 com opções IP, muito raros no tráfego legítimo. Não toca no IPv6 nem noutros protocolos, e remove-se com um só comando.

O meu Windows Server é afetado?

Não. É uma vulnerabilidade do kernel Linux.

Está a ser explorada?

No momento da publicação não se conhece nenhum exploit público, e o CVE não consta do catálogo KEV da CISA. Atualizaremos este artigo se isso mudar.

---

Fontes

• CVE.org: registo oficial do CNA do Linux, publicado a 2026-10-15 e atualizado a 2026-10-24
• NVD: entrada do CVE com a pontuação do CNA (consultado a 2026-10-29)
• Ubuntu: estado por versão, prioridade High (atualizado a 2026-10-28)
• Debian Security Tracker: pacotes corrigidos, DSA-6568-1, DLA-4841-1 e DLA-4850-1 (consultado a 2026-10-29)
• Red Hat: classificação Moderate e estado «Fix deferred» (consultado a 2026-10-29)
• SUSE: estado por produto (consultado a 2026-10-29)
• Commit da correção no Linux: «ipv4: free inet_opt and ireq_opt after an RCU grace period» (2026-10-01)
• kernel.org: versões estáveis atuais (consultado a 2026-10-29)
• CISA KEV: catálogo de vulnerabilidades exploradas, sem este CVE (consultado a 2026-10-29)