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-releaseNAME="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-01uname -r5.14.0-687.55.1.el9_8.x86_64nft --version-bash: nft: command not foundA 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 kernelkernel-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.
| Distribuição | Versão do kernel corrigido (esta versão ou superior) |
|---|---|
| AlmaLinux 8 | kernel-4.18.0-553.182.1.el8_10 |
| AlmaLinux 9 | kernel-5.14.0-687.64.1.el9_8 |
| AlmaLinux 10 | kernel-6.12.0-211.72.1.el10_2 |
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 -lnt4State 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.enablednet.mptcp.enabled = 0ss -lnMState Recv-Q Send-Q Local Address:Port Peer Address:PortAs 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
Linux 기반 블루프린트를 사용하는 인스턴스에 취약점(CVE-2026-98432)이 발생할 수 있습니다. 인스턴스가 영향을 받는지 확인하고 사용 중인 Linux 배포판에 최신 보안 업데이트를 적용하는 것이 좋습니다.
(us-east-1a)
스냅샷을 생성하여 인스턴스, 해당 시스템 디스크 및 연결된 디스크를 백업할 수 있습니다.
일일 스냅샷 시간은 오전 5:00 GMT+0입니다.Amazon은 가장 최근의 스냅샷 7개를 저장합니다.
🔲 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-headerskernel.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 appstreamdnf download kernel-core-5.14.0-687.64.1.el9_8Baixa 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: OKrpm -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 upgradeComo 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 rebootDepois que o servidor voltou, verificamos em sequência o kernel em execução, os kernels instalados e o kernel padrão.
uname -r5.14.0-687.64.1.el9_8.x86_64rpm -q kernelkernel-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_64grubby --default-kernel/boot/vmlinuz-5.14.0-687.64.1.el9_8.x86_64O 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.
| Item | Antes do patch | Depois do patch |
|---|---|---|
| Kernel em execução (uname -r) | 5.14.0-687.55.1.el9_8 | 5.14.0-687.64.1.el9_8 |
| Kernel padrão (grubby) | 5.14.0-687.55.1.el9_8 | 5.14.0-687.64.1.el9_8 |
| Kernels instalados (rpm -q kernel) | 5.14.0-611.30.1.el9_7, 5.14.0-687.49.1.el9_8, 5.14.0-687.55.1.el9_8 | 5.14.0-687.49.1.el9_8, 5.14.0-687.55.1.el9_8, 5.14.0-687.64.1.el9_8 |
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 nftablesO 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
}
}
EOFCria 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_98432Verifica 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_98432Depois 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 DROPA 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 DROPFechar 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
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.
ℹ️ 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.