Vulnerabilidade do kernel Linux CVE-2026-98432: bloqueio temporário e aplicação do patch do kernel

A CVE-2026-98432 é uma vulnerabilidade do kernel Linux em que o código do kernel que aceita conexões TCP IPv4 lê de novo uma memória já liberada, e a equipe de CVE do kernel Linux a classificou como Critical. Como é uma falha que pode ser atacada remotamente sem autenticação, atualizamos um servidor Lightsail com AlmaLinux 9.8, Nginx e Apache para os pacotes do kernel corrigido, reiniciamos e depois confirmamos o patch pela versão do kernel em execução.

1️⃣ Vulnerabilidade do kernel Linux CVE-2026-98432: como a falha funciona e o que ela afeta

Quando uma solicitação de conexão TCP (SYN) chega com opções IPv4, o kernel guarda uma cópia dessas opções junto com a conexão pendente para devolvê-las na resposta (SYN-ACK). Quando a conexão é estabelecida, essa cópia passa direto para o socket da nova conexão, sem ser duplicada.

Se nesse meio-tempo o cliente reenviar o SYN, outra CPU pode estar montando um SYN-ACK com as mesmas opções. Se a nova conexão for fechada nesse momento e o kernel liberar logo a memória das opções, o código que montava o SYN-ACK lê uma memória já liberada: um use-after-free.

Esse código roda enquanto o kernel processa a solicitação de conexão, antes de a aplicação ver a conexão. Por isso, seja qual for o serviço que abriu a porta, se ela estiver escutando por TCP IPv4, um ataque pode alcançá-la remotamente sem credenciais, e a pontuação é 9.8 pelo CVSS 3.1.

A falha existe desde o Linux 4.4, então a maioria dos servidores Linux é afetada. Entre os blueprints do Lightsail, o guia da AWS cita AlmaLinux 9, CentOS Stream 9, Debian, openSUSE Leap, Ubuntu, Amazon Linux 2 e Amazon Linux 2023. O anúncio da AlmaLinux inclui as versões 8, 9 e 10, e os blueprints de aplicativos do Lightsail, como WordPress e LAMP, também rodam sobre Debian ou Ubuntu e por isso também são afetados.

FreeBSD e Windows Server, que não usam o kernel Linux, ficam de fora.

Servidores com MPTCP (Multipath TCP) desativado também precisam do patch. O ataque publicado mirava servidores com um listener MPTCP aberto, mas a falha em si está no código TCP IPv4 comum; por isso o anúncio da AlmaLinux também diz que sistemas sem MPTCP precisam ser corrigidos.

O kernel corrigido só libera a memória das opções depois que passa um período de carência do RCU (grace period), de modo que a memória continua lá enquanto outra CPU lê as opções para montar um SYN-ACK.

2️⃣ Verificar a versão do kernel Linux: o kernel está corrigido?

A necessidade do patch depende da versão do kernel em execução, então antes de atualizar verificamos primeiro a distribuição e a versão do kernel.

cat /etc/os-release

NAME="AlmaLinux"
VERSION="9.8 (Olive Jaguar)"
ID="almalinux"
ID_LIKE="rhel centos fedora"
VERSION_ID="9.8"
PLATFORM_ID="platform:el9"
PRETTY_NAME="AlmaLinux 9.8 (Olive Jaguar)"
ANSI_COLOR="0;34"
LOGO="fedora-logo-icon"
CPE_NAME="cpe:/o:almalinux:almalinux:9::baseos"
HOME_URL="https://almalinux.org/"
DOCUMENTATION_URL="https://wiki.almalinux.org/"
BUG_REPORT_URL="https://bugs.almalinux.org/"

ALMALINUX_MANTISBT_PROJECT="AlmaLinux-9"
ALMALINUX_MANTISBT_PROJECT_VERSION="9.8"
REDHAT_SUPPORT_PRODUCT="AlmaLinux"
REDHAT_SUPPORT_PRODUCT_VERSION="9.8"
SUPPORT_END=2032-06-01

uname -r

5.14.0-687.55.1.el9_8.x86_64

nft --version

-bash: nft: command not found

A distribuição era AlmaLinux 9.8 e o kernel em execução era 5.14.0-687.55.1.el9_8. Também não existia o comando nft usado na regra de bloqueio temporário, ou seja, o pacote nftables não estava instalado.

rpm -q kernel

kernel-5.14.0-611.30.1.el9_7.x86_64
kernel-5.14.0-687.49.1.el9_8.x86_64
kernel-5.14.0-687.55.1.el9_8.x86_64

[rpm -q kernel] mostra a lista de kernels instalados, mas até reiniciar o único que realmente está rodando é o que aparece em [uname -r]. Compare essa versão com a versão corrigida do anúncio da AlmaLinux.

5.14.0-687.55.1.el9_8 era menor que 5.14.0-687.64.1.el9_8, a versão corrigida do AlmaLinux 9, então precisava de atualização.

Para ver se havia um caminho aberto para o ataque, verificamos as portas TCP IPv4 em escuta e o estado do MPTCP.

ss -lnt4

State  Recv-Q Send-Q Local Address:Port Peer Address:Port
LISTEN 0      128          0.0.0.0:22        0.0.0.0:*
LISTEN 0      511          0.0.0.0:443       0.0.0.0:*
LISTEN 0      511          0.0.0.0:80        0.0.0.0:*

sysctl net.mptcp.enabled

net.mptcp.enabled = 0

ss -lnM

State Recv-Q Send-Q Local Address:Port Peer Address:Port

As portas TCP IPv4 escutando em todos os endereços (0.0.0.0) eram a 80 e a 443 do servidor web e a 22 do SSH.

[net.mptcp.enabled] era 0 e não havia sockets MPTCP, então o caminho MPTCP usado pelo ataque publicado estava fechado. Mas a falha começa nas conexões TCP IPv4 comuns, então um servidor que escuta em três portas IPv4 continua precisando do patch.

3️⃣ Atualização do kernel Linux: sete pacotes do kernel e uma reinicialização

Antes de trocar o kernel, criamos um snapshot manual da instância no console do Lightsail. O Lightsail não tem tela para escolher o kernel de inicialização; se o servidor não subir com o novo kernel, você restaura criando uma nova instância a partir desse snapshot.

🔲 Simulador de snapshots do Lightsail

🔲 Verificar a atualização do kernel Linux e a reinicialização

Verificamos a versão do kernel corrigido publicada no repositório com uma listagem do dnf.

dnf --showduplicates list available kernel kernel-core kernel-modules kernel-modules-core kernel-tools kernel-tools-libs kernel-headers

kernel.x86_64                 5.14.0-687.64.1.el9_8   baseos
kernel-core.x86_64            5.14.0-687.64.1.el9_8   baseos
kernel-modules.x86_64         5.14.0-687.64.1.el9_8   baseos
kernel-modules-core.x86_64    5.14.0-687.64.1.el9_8   baseos
kernel-tools.x86_64           5.14.0-687.64.1.el9_8   baseos
kernel-tools-libs.x86_64      5.14.0-687.64.1.el9_8   baseos
kernel-headers.x86_64         5.14.0-687.64.1.el9_8   appstream

dnf download kernel-core-5.14.0-687.64.1.el9_8

Baixa só o arquivo do pacote kernel-core na pasta atual, sem instalar.

rpm -Kv kernel-core-5.14.0-687.64.1.el9_8.x86_64.rpm

    V4 RSA/SHA256 Signature, key ID b86b3716: OK

rpm -qp --changelog kernel-core-5.14.0-687.64.1.el9_8.x86_64.rpm | grep CVE-2026-98432

- ipv4: free inet_opt and ireq_opt after an RCU grace period (CKI Backport Bot) [RHEL-295635] {CVE-2026-98432}

A assinatura estava OK e o changelog tinha uma linha corrigindo a CVE-2026-98432. Os avisos de segurança do dnf (updateinfo) que verificamos em 3 de novembro ainda não traziam essa CVE, então com [dnf upgrade --security] não era possível obter esse kernel.

Por isso instalamos os sete pacotes do kernel especificando também a versão.

dnf install -y kernel-5.14.0-687.64.1.el9_8 kernel-core-5.14.0-687.64.1.el9_8 kernel-modules-5.14.0-687.64.1.el9_8 kernel-modules-core-5.14.0-687.64.1.el9_8 kernel-tools-5.14.0-687.64.1.el9_8 kernel-tools-libs-5.14.0-687.64.1.el9_8 kernel-headers-5.14.0-687.64.1.el9_8

================================================================================
 Package                Architecture Version                    Repository    Size
================================================================================
Installing:
 kernel                 x86_64    5.14.0-687.64.1.el9_8      baseos       1.1 M
 kernel-core            x86_64    5.14.0-687.64.1.el9_8      baseos        17 M
 kernel-modules         x86_64    5.14.0-687.64.1.el9_8      baseos        40 M
 kernel-modules-core    x86_64    5.14.0-687.64.1.el9_8      baseos        31 M
Upgrading:
 kernel-headers         x86_64    5.14.0-687.64.1.el9_8      appstream    2.6 M
 kernel-tools           x86_64    5.14.0-687.64.1.el9_8      baseos       1.3 M
 kernel-tools-libs      x86_64    5.14.0-687.64.1.el9_8      baseos       1.1 M
Removing:
 kernel                 x86_64    5.14.0-611.30.1.el9_7      @baseos        0
 kernel-core            x86_64    5.14.0-611.30.1.el9_7      @baseos       64 M
 kernel-modules         x86_64    5.14.0-611.30.1.el9_7      @baseos       33 M
 kernel-modules-core    x86_64    5.14.0-611.30.1.el9_7      @baseos       27 M

Transaction Summary
================================================================================
Install  4 Packages
Upgrade  3 Packages
Remove  4 Packages

Total download size: 94 M

Complete!

Quatro novos pacotes do kernel foram instalados, os três pacotes kernel-headers, kernel-tools e kernel-tools-libs foram atualizados e nenhum outro pacote mudou. Como a configuração [installonly_limit=3] mantém até três kernels instalados, os quatro pacotes do mais antigo, 5.14.0-611.30.1.el9_7, foram removidos, e do download até a conclusão levou 74 segundos.

O comando oficial indicado no anúncio da AlmaLinux baixa de novo as informações dos repositórios e depois atualiza todos os pacotes que têm atualização.

sudo dnf clean metadata && sudo dnf upgrade

Como outros pacotes além do kernel também são atualizados, os passos para atualizar a versão inteira da distribuição estão em Atualização do Alma Linux: 9.4 → 9.8 no LightSail.

O novo kernel só passa a valer depois de reiniciar.

systemctl reboot

Depois que o servidor voltou, verificamos em sequência o kernel em execução, os kernels instalados e o kernel padrão.

uname -r

5.14.0-687.64.1.el9_8.x86_64

rpm -q kernel

kernel-5.14.0-687.49.1.el9_8.x86_64
kernel-5.14.0-687.55.1.el9_8.x86_64
kernel-5.14.0-687.64.1.el9_8.x86_64

grubby --default-kernel

/boot/vmlinuz-5.14.0-687.64.1.el9_8.x86_64

O servidor voltou em menos de um minuto depois do comando de reinicialização, e tanto o kernel em execução quanto o kernel padrão da próxima inicialização passaram a ser 5.14.0-687.64.1.el9_8. O kernel anterior, 5.14.0-687.55.1.el9_8, continua instalado; se o novo kernel der problema, você pode voltar o kernel padrão.

4️⃣ Bloqueio temporário antes de reiniciar: regras nft e seus limites

Se você não puder reiniciar logo, dá para bloquear com uma regra temporária os pacotes que disparam a falha até instalar o kernel corrigido. Os comandos desta seção não foram executados por nós; seguem a orientação oficial (os anúncios da AlmaLinux e da AWS).

No servidor Lightsail com AlmaLinux 9.8, Nginx e Apache, uma reinicialização leva só alguns minutos, então atualizamos o kernel direto, sem bloqueio temporário.

A falha só é disparada por solicitações de conexão TCP que trazem opções IPv4. O tráfego comum quase não usa opções IPv4, então bloquear só os pacotes TCP IPv4 com opções mantém as conexões normais funcionando.

sudo dnf install -y nftables

O comando nft fica no pacote nftables, instalado junto com o firewalld. Se o seu servidor não tiver o comando, instale-o primeiro.

sudo nft -f - <<'EOF'
add table ip cve_2026_98432
delete table ip cve_2026_98432
table ip cve_2026_98432 {
    chain prerouting {
        type filter hook prerouting priority -300; policy accept;
        meta l4proto tcp ip hdrlength > 5 counter drop
    }
}
EOF

Cria uma tabela que descarta na etapa prerouting os pacotes TCP com comprimento de cabeçalho IPv4 maior que 5, ou seja, pacotes com opções IPv4. É uma regra que a AlmaLinux testou no 8, 9 e 10; pode ser usada junto com o firewalld e é seguro executá-la várias vezes.

sudo nft list table ip cve_2026_98432

Verifica se a regra entrou; o valor de counter na saída é o número de pacotes bloqueados até agora.

sudo nft delete table ip cve_2026_98432

Depois de reiniciar com o kernel corrigido, apague a tabela com este comando.

Esta regra some ao reiniciar; se você reiniciou antes de instalar o kernel corrigido, execute de novo o comando que cria a tabela.

Esta regra não serve para servidores com aplicações que dependem de opções IPv4. Um exemplo são as redes que usam rótulos de segurança CIPSO (NetLabel), transportados nas opções IPv4; na configuração padrão eles não são usados.

A regra protege o host e os contêineres que recebem tráfego através do host (o modo padrão do Podman e do Docker). O tráfego trocado entre contêineres do mesmo host pode passar por fora desta regra.

No Debian, Ubuntu e openSUSE, use a regra de iptables de uma linha do guia da AWS. Os kernels do AlmaLinux 9 e do CentOS Stream 9 não têm o match u32 que essa regra usa, então use a regra nft acima.

sudo iptables -I INPUT 1 -p tcp -m u32 --u32 '0>>24&0x0f=6:15' -j DROP

A expressão u32 lê o campo de comprimento do cabeçalho IPv4; se o valor for maior que 5, o pacote traz opções IPv4. Depois de instalar o kernel corrigido, apague esta regra com o comando abaixo.

sudo iptables -D INPUT -p tcp -m u32 --u32 '0>>24&0x0f=6:15' -j DROP

Fechar no firewall do Lightsail as portas que você não usa e limitar as restantes a endereços IP confiáveis é outra medida recomendada pelo guia da AWS.

🔢 FAQ & conteúdo recomendado

🔗 Conteúdo recomendado

Outra resposta a CVE: OpenSSH Vulnerabilidade do OpenSSH CVE-2024-6387: bloqueio temporário e aplicação do patch A vulnerabilidade do OpenSSH CVE-2024-6387 explora o sinal de alarme disparado quando quem se conecta não termina o login em 120 segundos. Resumimos nesta ordem: desligar o alarme para fechar a brecha urgente, corrigir o código com uma atualização e depois desfazer a mudança. Ver post →

Versão do kernel Comandos para verificar a versão do kernel Linux e como verificar a versão da distribuição No Linux, você verifica a versão do kernel com o comando uname. Gerenciamento de pacotes Comando dnf: instalar, atualizar e remover pacotes e a diferença para o yum O comando dnf é o comando de gerenciamento de pacotes para pesquisar, instalar, atualizar e remover pacotes no Linux da família RHEL. Vulnerabilidade do PHP Vulnerabilidade do PHP: patch do PHP2Shell e como verificar a versão do PHP (WordPress) É uma falha de execução remota de código que permite rodar código no servidor até com requisições sem login, então o primeiro passo é verificar a versão do PHP que o seu site usa e subir para uma versão com patch.

ℹ️ Aviso de afiliados
O conteúdo deste site contém links de afiliados. Quando um visitante compra um produto ou serviço por meio de um desses links, o site recebe uma comissão do vendedor. O valor que o comprador paga ^{(em promoções, ele diminui ↓)} não aumenta por causa disso. Preços, descontos e informações de estoque valem para o momento em que o texto foi escrito e podem ter mudado, por isso confirme com o vendedor antes de comprar. Os produtos são escolhidos e avaliados por critérios próprios, e o recebimento de comissão não influencia a ordem de apresentação nem o conteúdo das avaliações.