A vulnerabilidade CVE-2026-98276 foi corrigida no código-fonte original. Em seguida, um servidor travou 12 vezes.

Principais conclusões

• A vulnerabilidade CVE-2026-98276 permite que um usuário local sem privilégios provoque uma corrida de execução entre duas chamadas de socket para travar o kernel ou obter privilégios de root.
• Uma vulnerabilidade que causava a falha de um servidor 12 vezes agora permite obter privilégios de root nas versões EL 8, 9 e 10.
• A Red Hat não disponibiliza um kernel corrigido para o RHEL 7, 8, 9 ou 10 e não indica nenhuma medida de mitigação.
• Os patches do KernelCare que não exigem reinicialização já estão disponíveis para RHEL, AlmaLinux e CloudLinux 8 e 9, além do Debian 12 e 13.

A versão resumida

Ir para a versão completa ↓

O que aconteceu: Em 6 de outubro de 2026, a equipe de CVE do kernel CVE-2026-98276 publicado, uma falha do tipo “use-after-free” em soquetes UDP causada por uma corrida entre bind() e sock_gettstamp(), o manipulador que avisa um programa quando o último pacote de um soquete chega. Qualquer usuário local capaz de abrir um soquete UDP pode acioná-lo, mas ele não pode ser acessado pela rede. Em 4 de novembro, uma exploração funcional foi usada contra um servidor CloudLinux 8 e bateu com ele 12 vezes. Ir para esta seção → (Como foi o ataque em um servidor real) . Desde então, a TuxCare desenvolveu um exploit de root funcional a partir do código recuperado daquele servidor.

Quem é afetado: Qualquer kernel que ainda não tenha recebido a correção, o que ainda abrange muitos sistemas de produção. Isso inclui o RHEL 7, 8, 9 e 10, bem como as versões recompiladas que utilizam o kernel da Red Hat, incluindo o CloudLinux 8, 9 e 10. A hospedagem compartilhada é o ponto fraco, pois as contas dos clientes nesse tipo de serviço costumam executar seu próprio código em um kernel compartilhado por todos. Ir para esta seção →

Situação atual:Não se trata de uma vulnerabilidade “zero day”. A correção já estava disponível no código-fonte original e nos ramos estáveis do código-fonte original antes de qualquer ataque ter sido relatado, e nenhum código de exploração foi divulgado publicamente. A TuxCare confirmou agora a escalada de privilégios no EL 8, 9 e 10, incluindo o kernel mais recente do AlmaLinux 8; portanto, considere isso como acesso root local nessas versões. No EL 7, a avaliação da TuxCare indica apenas uma falha no sistema. O Debian corrigiu os kernels; o Ubuntu, a Oracle e a Amazon corrigiram alguns; e a Red Hat ainda não lançou uma correção para nenhuma versão do EL nem informou uma data. Os patches sem reinicialização da KernelCare já estão em produção para RHEL, AlmaLinux e CloudLinux 8 e 9, e o EL 10 está no canal de testes. Ir para esta seção →

O que fazer hoje: Não há nenhuma opção do sysctl para ativar nem nenhuma regra de firewall que ajude, então aplicar o patch é a única solução real. No RHEL, no AlmaLinux e no CloudLinux 8 e 9, além do Debian 12 e 13, os usuários do KernelCare podem baixar o patch agora mesmo:

kcarectl --update

Então, verifique isso com kcarectl --patch-info | grep 'CVE-2026-98276'. No EL 10, que inclui o CloudLinux 10, o patch está disponível no canal de testes por enquanto; portanto, adicione –prefix test ao comando de atualização. Até que o patch esteja disponível, restrinja ou suspenda as contas locais nas quais você não confia. Ir para esta seção →

Falhas locais de negação de serviço geralmente ficam no fim da lista de prioridades. O invasor precisa de um ponto de acesso na máquina, o resultado típico é uma falha no sistema e uma reinicialização, e a maioria das frotas tem problemas mais graves para resolver. A CVE-2026-98276 parecia, a princípio, ser um desses casos, mas não ficou por aí.

Alguém já o utilizou. Em 4 de novembro, Um servidor CloudLinux 8 ficou fora do ar 12 vezes a partir de um exploit funcional para esse bug, e com kernel.panic_on_oops = 1 Uma vez configurado, cada falha significava uma reinicialização completa. Dois dias depois, a TuxCare obteve acesso root no AlmaLinux 8 por meio de uma exploração criada a partir do código recuperado daquele servidor, e a escalada de privilégios agora funciona no EL 8, 9 e 10. E não há nada para desativar. O código vulnerável está por trás de um ioctl de carimbo de data/hora que qualquer processo pode chamar em qualquer soquete UDP que abrir.

Os kernels dos fornecedores também estão atrasados. A correção já estava disponível no upstream antes da divulgação do CVE, em 6 de outubro; o Debian lançou kernels corrigidos há semanas; e a Red Hat ainda lista as versões do RHEL 7 a 10 como afetadas, sem nenhum kernel corrigido e sem data prevista.

Como uma consulta de carimbo de data/hora libera um soquete ativo

SIOCGSTAMP e SIOCGSTAMPNS, além do _NEW As versões que os kernels mais recentes utilizam para o tempo de 64 bits são ioctls antigas e pouco sofisticadas. Um programa chama uma delas em um soquete para perguntar quando o último pacote chegou, e o kernel responde por meio de sock_gettstamp() em net/core/sock.c. Na primeira vez que uma conexão é solicitada, o manipulador também ativa o registro de data e hora, definindo o SOCK_TIMESTAMP mordida em sk->sk_flags.

O problema é que ele faz isso sem segurar a chave de soquete, e o ajudante que está embaixo usa __set_bit(), o que não é uma operação atômica. A CPU lê a palavra de sinalizadores inteira, realiza uma operação OR em um bit e grava a palavra inteira de volta. Se alguma outra operação alterar um bit diferente nessa palavra entre a leitura e a gravação, essa alteração será perdida.

Esse outro escritor é bind(). Ao vincular um soquete UDP, udp_lib_get_port() conjuntos SOCK_RCU_FREE e adiciona o soquete à tabela hash, onde o caminho de recepção UDP pode encontrá-lo sem precisar bloquear o acesso. SOCK_RCU_FREE essa é a garantia do kernel para esses leitores que não utilizam bloqueios. Quando o soquete é fechado, o kernel aguarda um período de carência do RCU antes de liberá-lo, para que qualquer um que ainda esteja acessando-o possa concluir a operação.

Se você executar os dois em CPUs diferentes, a sincronização pode ficar prejudicada. O ioctl lê os sinalizadores logo antes de bind() conjuntos SOCK_RCU_FREE, e então grava sua cópia desatualizada de volta depois que o soquete já está na tabela. O sinalizador desapareceu, mas o soquete ainda está visível para leitores sem bloqueio, e nada no kernel sabe que a promessa foi quebrada. Se você fechá-lo enquanto um pacote está a caminho, o kernel libera a memória imediatamente, mesmo que o caminho de recepção ainda esteja usando-a. Isso é o que se chama de “use-after-free”.

O corrigir de Eric Dumazet encaixa a trava do soquete sock_gettstamp(), mas somente quando SOCK_TIMESTAMP na verdade precisa ser configurado, para que o caminho comum permaneça sem bloqueio. O Registro CVE atribui a autoria da reportagem a Jungwoo Lee e Wongi Lee, e a KASAN indica que as citações foram extraídas de um programa de teste mencionado pelos repórteres exploit.

A mesma mensagem de commit destaca que sk_set_memalloc() e sk_clear_memalloc() também alterar sk_flags sem o bloqueio. Seus chamadores (nbd, iSCSI, NVMe sobre TCP, sunrpc e WireGuard) precisam passar por uma auditoria primeiro, então o upstream planeja um patch separado. Essa é uma correção à parte para outro momento e não faz parte deste CVE.

Qualquer kernel que não tenha a correção ainda apresenta essa vulnerabilidade, e muitos kernels corporativos em produção ainda não a incorporaram.

O servidor atacado rodava um kernel do CloudLinux 8, e cada falha deixava o mesmo rastro no log do kernel. Primeiro, apareciam avisos nas linhas 153 e 156 do net/ipv4/af_inet.c, por dentro inet_sock_destruct(), o código que encerra uma conexão de socket. Em seguida, ocorreu uma desreferência de ponteiro NULL, seja em udp_destruct_common() à medida que o soquete se fechava ou ao __sk_mem_raise_allocated() chamado de __udp_enqueue_schedule_skb() enquanto um pacote estava sendo colocado na fila. Ambas as situações são o que se esperaria quando o caminho de fechamento e o caminho de recepção disputam um soquete que já não existe mais.

O servidor tinha kernel.panic_on_oops = 1, que é utilizado por muitas configurações de hospedagem para que um kernel com falhas reinicie, em vez de continuar funcionando precariamente. Isso transformou cada “oops” em uma reinicialização – foram doze no total. O usuário root nunca teve acesso a esse servidor; ocorreram apenas as falhas, e nenhum código de exploração foi divulgado publicamente.

Se um servidor estiver reiniciando sem motivo aparente, verifique o log do kernel da inicialização anterior em busca desses nomes de funções. Para isso, é necessário um diário persistente:

journalctl -k -b -1 | grep -E 'inet_sock_destruct|udp_destruct_common|__sk_mem_raise_allocated|__udp_enqueue_schedule_skb'

Uma correspondência, por si só, não é prova de um ataque, mas, em um kernel sem patches, é um bom motivo para verificar quem estava conectado e o que estava sendo executado.

De “Crash Bug” a “Root Bug”

A equipe do kernel responsável pelo CVE classificou o CVE-2026-98276 com nota 7,8 (Alto), com um vetor de ataque local, baixa complexidade de ataque, privilégios baixos e alto impacto na confidencialidade, integridade e disponibilidade. A Red Hat classifica-o como “Moderado” com nota 7,0, e a SUSE e a Amazon também atribuem nota 7,0. Toda a diferença está na complexidade do ataque, que esses fornecedores classificam como alta porque o invasor precisa vencer uma corrida de tempo. Esse é um argumento válido em teoria, mas o incidente com o CloudLinux 8 mostra que é possível vencer essa corrida em um servidor de produção, repetidamente.

A maior discrepância estava entre a pontuação e as evidências, e essa discrepância foi sanada. O vetor 7.8 pressupõe que uma vulnerabilidade do tipo “use-after-free” em soquetes, como esta, possa ser transformada em escalada de privilégios, e a TuxCare conseguiu fazer isso. Sua equipe obteve acesso root no AlmaLinux 8 com o kernel padrão, utilizando um exploit criado a partir do código recuperado do servidor atacado, e, desde então, confirmou a escalada de privilégios no EL 8, 9 e 10. Isso inclui o kernel mais recente do AlmaLinux 8, o 4.18.0-553.184.1.el8_10. O exploit não é totalmente confiável, mas já funcionou várias vezes. No EL 7, a avaliação da TuxCare aponta apenas para uma falha local. Em todas as outras versões da família EL, considere isso como acesso root local e atribua a isso maior prioridade do que a pontuação de 7,0 do fornecedor sugere.

O CloudLinux 9 e 10 utilizam kernels do AlmaLinux, portanto seguem a linha do AlmaLinux. No Ubuntu, o status depende da versão do kernel; portanto, verifique o pacote que você realmente está executando, em vez do número da versão. Se você compilar seus próprios kernels, qualquer uma das versões estáveis acima já contém a correção.

As versões mais antigas cobertas pelo Suporte de Ciclo de Vida Ilimitado (ELS) da TuxCare estão em melhor estado do que você imagina. Os kernels do ELS com essa correção foram lançados entre 14 e 26 de outubro para o CentOS 6, Oracle Linux 6, CentOS 8.5 e Ubuntu 20.04, juntamente com kernels de suporte estendido para o AlmaLinux 9.2 e 9.6.

A maioria dos bugs do kernel vem acompanhada de alguma configuração que pode ser ajustada enquanto o patch está a caminho, seja um módulo para descarregar ou um sysctl para alterar. Este aqui não tem nada disso. sock_gettstamp() Trata-se de código do soquete do kernel, e nenhum sysctl ou opção de inicialização o desativa. Qualquer usuário comum capaz de criar um soquete UDP pode acessá-lo e, em uma instalação padrão, isso inclui todos.

Um firewall não adianta. O gatilho são algumas chamadas de sistema em um soquete que pertence ao invasor, e nada disso passa pelo iptables ou pelo nftables.

Uma política do SELinux poderia bloquear os ioctls de registro de data e hora. No CloudLinux, porém, o cPanel & WHM exige que o SELinux esteja desativado, o que descarta essa opção para muitos servidores de hospedagem.

O que resta é restringir quem pode executar código no servidor. Na hospedagem compartilhada, isso inclui acesso ao shell, tarefas cron e qualquer aplicativo do cliente capaz de executar seus próprios binários. Restrinja ou suspenda as contas nas quais você não confia até que a correção seja aplicada e fique atento a reinicializações inexplicáveis, lembrando-se de que elas podem revelar apenas as tentativas malsucedidas. Em seguida, aplique a correção.

O patch sem reinicialização do KernelCare implementa a correção do upstream tal como está, mantendo o bloqueio de socket em torno da atualização do sinalizador. Trata-se de uma pequena alteração, sem mudanças na estrutura de dados, o que a torna ideal para um patch sem reinicialização, e está sendo distribuída para toda a família EL, enquanto a Red Hat ainda não possui um kernel corrigido para nenhuma versão EL. O LibCare não está envolvido, já que se trata de um bug do kernel.

O EL 7 é a exceção. A avaliação da TuxCare indica que se trata de uma falha local sem escalonamento de privilégios; portanto, não há planos de corrigir essa vulnerabilidade antes da Red Hat. Em todos os casos em que uma correção está em produção, os hosts com atualizações automáticas do KernelCare a recebem de acordo com sua programação normal; ou você pode baixá-la imediatamente com o comando `kcarectl –update`. No EL 10, incluindo o CloudLinux 10, a correção está no feed de teste por enquanto; portanto, use o comando `kcarectl –update –prefix test`. Não é necessário reiniciar o sistema em nenhum dos casos. Em seguida, verifique se a correção foi realmente aplicada:

kcarectl --patch-info | grep 'CVE-2026-98276'

Se nada for exibido, significa que o KernelCare ainda não aplicou um patch para essa CVE; portanto, verifique se o host já está executando um kernel corrigido pelo fabricante antes de presumir que ele esteja vulnerável. O TuxCare CVE Tracker mostra o status dos patches que não exigem reinicialização por distribuição, à medida que há atualizações.

Adquira o KernelCare hoje mesmo →

Algumas linhas de bloqueio e uma longa espera

A correção no código-fonte consiste em apenas algumas linhas, e os usuários do RHEL ainda não têm um kernel do fornecedor para instalar.

Pelos critérios habituais, ninguém deveria ter percebido essa vulnerabilidade. A correção foi lançada antes do CVE, o CVE foi divulgado um mês antes de qualquer ataque ocorrer e nenhum código de exploração foi divulgado publicamente. Em teoria, um bug que causa travamento local com uma pontuação do fornecedor de 7,0 não é prioridade.

Então, surgiu um exploit funcional em um servidor de hospedagem em produção, enquanto os kernels da família RHEL — que muitos servidores de hospedagem utilizam — ainda não contam com uma correção do fabricante. Em dois dias, esse mesmo código de exploit havia sido transformado em um exploit de root. A hospedagem compartilhada é quase o pior cenário possível para um bug local. Muitos clientes podem executar seus próprios códigos em uma conta local, e basta apenas um deles para derrubar o servidor ou assumir o controle dele, afetando todos os demais usuários nele.

Portanto, se você administra servidores multilocatários, não classifique essa vulnerabilidade como DoS local. Nas versões EL 8 a 10, trata-se de um acesso root local. Verifique os logs em busca da assinatura de falha, restrinja o acesso às contas nas quais você não confia e aplique a correção — seja por meio de um patch sem reinicialização, quando disponível, ou reiniciando o sistema com um kernel corrigido, caso sua distribuição ofereça essa opção.

Adquira o KernelCare hoje mesmo →

Como tudo aconteceu

Fontes

As fontes primárias para esta publicação são o anúncio do CVE do kernel, o registro do CVE e a correção do desenvolvedor original, além das páginas dos fornecedores Red Hat (incluindo seu sistema de rastreamento de bugs), Debian, Ubuntu, SUSE, Amazon e Oracle. Também são citados o relatório de incidente da CloudLinux, a entrada no NVD, o registro da OSV e os registros de lançamento do KernelCare e do ELS da TuxCare, com data de 9 de novembro de 2026.