Três bugs antigos do kernel do Linux foram adicionados à lista KEV da CISA

A versão resumida

Ir para a versão completa ↓

O que são: Em 18 de setembro de 2026, a CISA adicionou três vulnerabilidades do kernel do Linux ao seu catálogo de Vulnerabilidades Conhecidas como Exploradas. A CVE-2025-39682 está localizada no caminho de recepção TLS do kernel, a CVE-2026-53266 está no destino SNAT do ebtables usado em pontes de rede e a CVE-2025-39964 é uma condição de corrida nos soquetes criptográficos AF_ALG. Três subsistemas não relacionados, três testes de exposição diferentes. Ir para esta seção →

Impacto: varia muito mais do que as manchetes sugerem. O bug do kTLS permite que registros posteriores sejam processados com base em suposições incorretas sobre zero-copy e enfileiramento. O bug do ebtables pode fazer com que uma gravação do kernel seja direcionada para uma página respaldada por arquivo que nunca deveria ter sido modificada por esse caminho, o que a Red Hat descreve como um caminho para corrupção de memória, negação de serviço ou escalonamento de privilégios. A corrida de acesso AF_ALG, por si só, causa uma falha local ou saída criptográfica corrompida, mas um código de exploração público agora a encadeia para gerar um shell de root em um kernel alvo. Ir para esta seção →

Gravidade: É uma questão mais complexa do que as manchetes sugerem. A Red Hat atribui a elas as notas 7,0, 7, 5 e 7,3, classificando-as como “Moderada”, “Importante” e “Moderada”, respectivamente, já que seu nível de gravidade reflete mais do que apenas o número bruto. O NVD e o Linux CNA utilizam vetores diferentes para algumas dessas vulnerabilidades, e é daí que vêm os valores mais altos de 9,8, 8,8 e 7,8. Ir para esta seção →

Quem é afetado: o RHEL e suas versões derivadas, incluindo AlmaLinux, Rocky Linux, Oracle Linux e CloudLinux, com escopo que varia de acordo com cada CVE. Para o CVE-2025-39682, a Red Hat indica que apenas o EL9 e o EL10 são afetados. Os outros dois têm um escopo mais amplo, e o CVE-2026-53266 agora inclui até mesmo o RHEL 6 em suporte estendido. Cada vulnerabilidade também possui uma pré-condição que reduz a exposição real. Ir para esta seção →

Status: Não são vulnerabilidades “zero-day”. Todas as correções do desenvolvedor original são anteriores à publicação da lista, sendo que as correções para kTLS e AF_ALG são anteriores em mais de um ano. Os registros da Red Hat agora sinalizam as três como exploits conhecidas, mas nem a CISA nem a Red Hat publicaram uma cadeia de ataque, alvos ou telemetria além do status vinculado ao KEV, e o uso em ransomware é listado como desconhecido. Também já existe código de exploit público para duas das três. Ir para esta seção →

Faça isso agora: instale um kernel fixo do fornecedor e reinicie o sistema com ele, ou deixe que o KernelCare aplique os patches dinâmicos sem reinicialização, quando estiverem disponíveis para o kernel específico em execução. E ignore a lista negra do módulo af_alg. Nos kernels do Enterprise Linux verificados aqui, o AF_ALG já vem integrado, portanto a lista negra não tem efeito. Ir para esta seção →

Antes de confiar em qualquer solução alternativa para o af_alg, verifique como o AF_ALG está integrado ao kernel em execução:

grep -E 'CONFIG_CRYPTO_USER_API' /boot/config-(uname-r)2>/dev/null||grep-E'CONFIGCRYPTOUSERAPI'/lib/modules/(uname -r)/config

Se CONFIG_CRYPTO_USER_API=y aparece na saída, o AF_ALG está compilado e nenhuma lista negra de módulos pode desativá-lo.

O fato de três CVEs do kernel terem sido registrados no KEV no mesmo dia pode parecer um único evento. Na verdade, são três eventos distintos, sem nenhuma classe de bug em comum, sem nenhum subsistema comum e sem nenhum teste específico que indique se um host está vulnerável.

O que eles compartilharam foi o momento e o alvoroço em torno do assunto. A listagem veio acompanhada de um prazo de três dias para correção por parte das agências civis federais, de acordo com a BOD 26-04, e a cobertura que se seguiu citou uma pontuação de gravidade de 9,8 e afirmou que a Red Hat havia confirmado, de forma independente, a exploração ativa em todas as três. Os registros da Red Hat realmente sinalizam os CVEs como vulnerabilidades conhecidas, mas esse status está vinculado à lista do KEV, e não à telemetria publicada pela Red Hat; além disso, a pontuação de 9,8 precisa de contexto, pois provém de uma avaliação de pontuação diferente daquela que a Red Hat utiliza para o RHEL.

Além disso, nenhum desses bugs é novo. A correção do kTLS foi incorporada ao código-fonte original em 19 de agosto de 2025, a do AF_ALG em 16 de setembro de 2025 e a do ebtables em 23 de maio de 2026. Portanto, trata-se de um problema de atraso na aplicação de patches, e a questão relevante para cada host é se a correção chegou ou não ao kernel que está realmente em execução.

A CISA incluiu todas as três CVEs no catálogo do KEV em 18 de setembro e estabeleceu o prazo de 21 de setembro, conforme a diretriz BOD 26-04, para que as agências civis federais implementassem as medidas corretivas. Três dias é um prazo curto para os padrões do KEV.

A inclusão significa que a CISA possui evidências de exploração que considera confiáveis. Isso não significa que essas evidências sejam públicas, e, neste caso, não são. As entradas do catálogo não contêm detalhes técnicos, o alerta que as acompanha não menciona nada sobre cadeias de ataque ou alvos, e todas as três listam o uso em campanhas conhecidas de ransomware como “Desconhecido”.

Os registros da Red Hat agora incluem um sinalizador de “vulnerabilidade com exploração conhecida” para todas as três, mas a Red Hat não publicou seus próprios detalhes sobre a exploração, cadeias de ataque, alvos ou telemetria, e o sinalizador segue a lista do KEV, em vez de se basear em observações independentes da Red Hat. Considere-o como o mesmo indicador fornecido pelo KEV, e não como uma segunda fonte.

Portanto, considere a lista como um indício confiável de que a CISA possui evidências de que essas vulnerabilidades estão sendo exploradas e, em seguida, avalie cada uma delas em função de suas pré-condições reais. A designação KEV aumenta a prioridade, mas a urgência prática ainda depende da acessibilidade de cada caminho vulnerável no host.

Os números 9,8, 8,8 e 7,8 que circulam são reais, e as pontuações específicas dos produtos da Red Hat são diferentes: 7,0 para o CVE-2025-39682, 7,5 para o CVE-2026-53266 e 7,3 para o CVE-2025-39964. As diferenças decorrem de diferentes vetores e premissas sobre a explorabilidade e o impacto.

O CVE-2025-39682 é um bom exemplo. O NVD atribui a ele uma pontuação de 9,8, enquanto a Red Hat atribui 7,0 para o RHEL. Ambos o consideram acessível pela rede, mas a Red Hat atribui “Alta” complexidade de ataque e menor impacto na confidencialidade e integridade; assim, a mesma falha é classificada de maneira muito diferente.

Essa distinção é importante para a análise, mas não deve se tornar um motivo para adiar a correção. Todas as três estão no catálogo KEV da CISA, e a questão relevante não é qual pontuação prevalece. Verifique se a vulnerabilidade é acessível em seus sistemas, priorize com base nisso, aplique o kernel corrigido ou o patch dinâmico e verifique se o kernel em execução está de fato protegido.

A vulnerabilidade CVE-2025-39682 está localizada no lado de recepção do TLS do kernel, a camada de registros interna do kernel que permite que os aplicativos transfiram parte do processamento de registros TLS para o kernel após o handshake.

Cada recvmsg() A chamada deve processar uma sequência de registros de dados contíguos ou um único registro que não seja de dados, nunca uma mistura dos dois. Um registro de comprimento zero já enfileirado em rx_list passa despercebido pela verificação de tipo do registro, de modo que os registros subsequentes são tratados com suposições incorretas sobre “zero-copy” e enfileiramento. Essa incompatibilidade compromete as suposições do caminho de recepção sobre os registros e os buffers que ele mantém, razão pela qual a Red Hat classifica esse problema como algo mais grave do que um simples bug de disponibilidade.

A acessibilidade é o que importa. Ter CONFIG_TLS no kernel não é suficiente. O protocolo de camada superior TLS precisa estar associado a um soquete TCP, o que só ocorre quando há uma opção ativa, como em uma implantação do nginx configurada para usar kTLS, um aplicativo desenvolvido com base em um caminho kTLS compatível do OpenSSL ou NFS sobre TLS por meio de tlshd. Quando o kTLS está habilitado intencionalmente e o aplicativo permite desativá-lo, desativar o offload faz com que o processamento dos registros volte para o espaço do usuário, o que acarreta algum custo de CPU. Considere isso como uma medida de mitigação provisória, e não como um substituto para a aplicação de patches.

A correção está no commit do upstream 62708b9452f8, datado de 19 de agosto de 2025. A Red Hat lançou kernels corrigidos do RHEL 9 e do RHEL 10 em 29 de setembro de 2025, com as versões 9.2 SAP e 9.4 EUS sendo lançadas no final de outubro. Para este CVE, a Red Hat classifica o RHEL 6, 7 e 8 como “Não afetados”. O código vulnerável foi introduzido no upstream do Linux 6.0 e está presente nos fluxos do kernel do RHEL 9 e 10, mas não no RHEL 8 baseado no 4.18 ou versões anteriores. Desde então, surgiu um código de exploração público que aproveita essa falha para causar corrupção de memória no kernel e obter um shell de root contra um alvo específico do kernelCTF; embora não seja o mesmo que uma exploração portátil para kernels RHEL em produção, isso significa que o bug do caminho de recepção já foi transformado em arma em algum lugar.

O bug de SNAT do Ebtables que grava na página errada

A vulnerabilidade CVE-2026-53266 apresenta o maior índice CVSS da Red Hat entre as três, 7,5, com classificação de gravidade “Importante” da Red Hat, e possui o modo de falha mais interessante.

O destino SNAT do ebtables pode, opcionalmente, reescrever o endereço físico do remetente dentro dos pacotes ARP à medida que eles atravessam uma ponte. Isso é feito por meio de skb_store_bits(), que grava nos fragmentos não lineares do pacote. Um desses fragmentos pode ser respaldado por uma página de arquivo importada por meio de splice, de modo que a gravação pode ocorrer em uma página respaldada por arquivo que nunca deveria ter sido modificada por esse caminho. A Red Hat associa isso ao CWE-825 e descreve o resultado como um caminho para corrupção de memória, negação de serviço ou escalonamento de privilégios.

A condição prévia é rigorosa. É necessário que haja uma regra SNAT do ebtables configurada pelo administrador com reescrita de ARP em uma ponte, e um invasor não pode ativar essa regra. Muitos hosts conectados por ponte nunca utilizam o NAT do ebtables. Como uma primeira verificação rápida, verifique se há uma regra SNAT com reescrita de ARP na tabela de NAT:

sudo ebtables -t nat -L | grep -i 'snat-arp'

Considere isso como uma verificação inicial da configuração, e não como uma prova definitiva em nenhum dos sentidos. A ausência de resultados correspondentes é um forte indício de que a regra não está configurada naquele host. Uma correspondência deve levar o host para o topo da fila de correção, sujeito ao seu próprio processo de alteração. Se a reescrita não for realmente necessária, desativar essa regra específica pode reduzir a exposição até que o kernel corrigido esteja instalado; no entanto, verifique se a alteração está de acordo com o projeto de rede antes de aplicá-la.

A correção no upstream é o commit 67ba971ae025, datado de 23 de maio de 2026. A Red Hat corrigiu as vulnerabilidades no RHEL 8 e no RHEL 9 em julho, bem antes da publicação da lista, e seguiu com o RHEL 10 e o RHEL 7 ELS em 24 de setembro, e depois com o RHEL 6 ELS em 30 de setembro. O kernel-rt do RHEL 9 ainda está marcado como afetado.

Dois gravadores em uma porta AF_ALG

CVE-2025-39964 é um bug de concorrência no AF_ALG, a interface de soquete que expõe a API de criptografia do kernel ao espaço do usuário. Duas gravações simultâneas no mesmo soquete AF_ALG podem se intercalar e deixar o contexto de cada soquete inconsistente.

A Red Hat descreve a falha direta como algo que permite que um usuário local cause uma falha no sistema ou corrompa resultados criptográficos. As pontuações, então, divergem. A pontuação principal do NVD é 5,5, referindo-se apenas ao impacto na disponibilidade. O Linux CNA atribui uma pontuação de 7,8, enquanto a Red Hat atribui 7,3, com um vetor que inclui o impacto na confidencialidade e na integridade. O que faz a diferença é a exploração pública. Um repositório encadeia a condição de corrida de execução levando à corrupção da memória do kernel, vaza um endereço do kernel e sobrescreve core_pattern, e consegue um shell de root. Tanto as próprias anotações do autor quanto uma análise independente apontam para offsets codificados e uma contornada do KASLR que podem não funcionar em todos os kernels; portanto, trata-se de uma cadeia comprovada de escalonamento de privilégios em uma compilação específica, e não de uma exploração portátil contra versões compatíveis do RHEL. De qualquer forma, a interpretação de que a vulnerabilidade causa apenas travamento não se sustenta mais, e isso é relevante em hosts compartilhados ou com múltiplos usuários.

A correção no upstream é o commit 1b34cbbf4f01, datado de 16 de setembro de 2025. Esse também é o CVE para o qual a Red Hat disponibilizou correções mais rapidamente após a publicação. Em 21 de setembro, a Red Hat não tinha nenhuma errata relacionada a ele em nenhum produto. A primeira errata foi publicada em 22 de setembro e, em 24 de setembro, já haviam sido disponibilizadas correções para o RHEL 8, 9, 10 e o RHEL 7 ELS, além das variantes com suporte estendido.

A solução alternativa para o AF_ALG que não resolve nada

Esse aqui vai causar problemas pra galera.

As orientações anteriores da Red Hat sobre o CVE-2025-39964 recomendavam evitar o af_alg impede que o módulo seja carregado. A página atual não contém mais essa linha, e ainda bem, pois ela nunca funcionou nos kernels do Enterprise Linux verificados aqui. O AF_ALG é integrado ao kernel nessas versões, em vez de ser fornecido como um módulo carregável. Os kernels fornecidos no AlmaLinux 8, 9 e 10 e no CloudLinux 8 definem CONFIG_CRYPTO_USER_API=y, com a implementação do AF_ALG e suas interfaces integradas. O modules.builtin listas de arquivos kernel/crypto/af_alg.ko, e o pacote não contém nenhum af_alg.ko.

A modprobe.d A lista negra pode, portanto, ser aceita sem gerar erro, mas não pode desativar um componente integrado. O mesmo se aplica a modprobe.blacklist=af_alg na linha de comando do kernel. Não foi encontrado nenhum parâmetro sysctl ou de inicialização compatível nas configurações testadas que desative o AF_ALG.

E a verificação que a maioria das pessoas costuma fazer está errada:

lsmod | grep af_alg

A saída vazia não comprova que o AF_ALG esteja inativo. Nos kernels verificados aqui, isso é consistente com o fato de o AF_ALG estar integrado ao kernel, em vez de ser carregado como um módulo, o que você pode confirmar com o CONFIG_CRYPTO_USER_API o comando `grep` mencionado no início desta postagem e com modules.builtin. Um host não deve ser considerado protegido apenas porque esse comando não retorna nada. Se a configuração indicar =y, as opções reais são um kernel corrigido ou um patch que não requer reinicialização. Como medida de defesa em profundidade, uma política de seccomp cuidadosamente testada pode bloquear socket() requer a família de endereços AF_ALG para determinadas cargas de trabalho, mas isso é específico para cada carga de trabalho e não oferece proteção contra usuários locais comuns no host.

Aqui está a situação das três principais famílias de Enterprise Linux, com base nas fontes analisadas até 2 de outubro de 2026. Cada célula apresenta, em primeiro lugar, o status do kernel do fornecedor e, no caso do AlmaLinux e do CloudLinux, inclui a cobertura do KernelCare sem reinicialização quando houver diferença, já que se trata de dois tipos distintos de correção. Leia os rótulos, em vez de se basear apenas nas datas:

O Rocky Linux e o Oracle Linux não estão listados acima, mas seguem o mesmo código de origem que o RHEL; portanto, verifique os avisos de segurança específicos de cada um e o kernel exato em execução, em vez de presumir que as datas correspondam. As versões do Suporte Estendido a Atualizações (EUS) da Red Hat para o RHEL 8 (8.4, 8.6, 8.8) e do RHEL 9 (9.2, 9.4, 9.6) também receberam correções entre 23 e 24 de setembro, enquanto as versões principais mais antigas, RHEL 6 e 7, são atendidas por meio do Suporte de Ciclo de Vida Estendido (ELS), ao qual se referem as notas sobre o ELS na tabela.

Duas observações breves. No CloudLinux 8, os kernels do 4.18.0-553.142.1 As versões posteriores já vêm com a correção do CVE-2026-53266 incorporada, portanto, verifique uname -r antes de presumir a existência de uma vulnerabilidade. E a Red Hat alterou a classificação do RHEL 6 de “Não afetado” para “Afetado” em relação ao CVE-2026-53266 no final de setembro, lançando uma correção do RHEL 6 ELS em 30 de setembro, o que é relevante para quem ainda estiver executando o RHEL 6 ou o CloudLinux 6 sob o Suporte de Ciclo de Vida Estendido.

O Debian, o Ubuntu e o Amazon Linux acompanham essas CVEs em seus próprios cronogramas. Verifique o comunicado de segurança específico para o seu kernel, em vez de basear-se nas informações do RHEL.

Os patches sem reinicialização do KernelCare também abrangem as versões do RHEL, conforme mostrado na linha do tempo na caixa de status na parte superior desta postagem; portanto, a linha do RHEL acima reflete os próprios kernels da Red Hat, e não a ausência de uma opção de patch sem reinicialização.

Adquira o KernelCare hoje mesmo →

Um pacote de kernel corrigido armazenado no disco não altera o kernel na memória. Para uma atualização convencional, instale os pacotes de kernel corrigidos correspondentes à sua versão específica, reinicie o sistema e verifique o que está realmente em execução:

uname -r

Compare isso com o aviso da Red Hat ou com o aviso de recompilação, e não com o que estiver mais recente no disco. Um host que instalou a atualização há três semanas e nunca foi reiniciado ainda está rodando o kernel antigo.

Quando há um patch compatível disponível, o KernelCare aplica as correções correspondentes ao kernel ativo sem a necessidade de reinicialização. Essas correções são distribuídas como patches dinâmicos sem reinicialização nos canais listados anteriormente, e a disponibilidade dos patches dinâmicos varia de acordo com o kernel. As configurações com atualizações automáticas ativadas baixam novos patches periodicamente, e kcarectl --update solicita um quando necessário. Confirme quais dos três estão disponíveis no kernel em execução:

kcarectl --patch-info | grep -E 'CVE-2025-39682|CVE-2026-53266|CVE-2025-39964'

Se um CVE não aparecer para o kernel em execução, não deduza a cobertura com base em outra distribuição, outra versão secundária ou uma atualização de pacote que nunca tenha sido inicializada, e mantenha em vigor qualquer mitigação provisória validada até que isso ocorra. O CloudLinux 8 é um caso especial, em que um kernel recente pode já conter a correção do CVE-2026-53266 de forma nativa, mesmo que uma consulta ao live-patch não mostre nenhum patch separado.

Não. Todas as correções já estavam disponíveis publicamente no código-fonte original antes da publicação, e a Red Hat já havia lançado kernels corrigidos para o CVE-2025-39682 quase um ano antes. O que é novo publicamente é a designação KEV da CISA, que indica que as vulnerabilidades são conhecidas por serem exploradas, mas não fornece detalhes públicos sobre a exploração. Essa é uma história comum de “n-day”. Correções antigas do kernel que nunca foram aplicadas são exatamente o que os invasores procuram.

No entanto, vale a pena ser preciso em relação ao código de exploração. Já existem repositórios públicos com PoCs (provas de conceito) funcionais de escalonamento de privilégios para os CVE-2025-39682 e CVE-2025-39964, ambos criados para alvos específicos no estilo kernelCTF com offsets codificados. Trata-se de uma verdadeira arma, e não de uma exploração portátil contra uma frota de produção corrigida, mas que ainda não foi reiniciada; portanto, afirmar que “não há PoC público” está simplesmente errado neste momento, mesmo que a afirmação de que “qualquer pessoa pode obter acesso root em qualquer host” esteja igualmente errada.

Por que o Trio de Kernels da KEV é importante

Nenhum dos três possui uma via de ataque ampla e sem pré-requisitos. Um deles requer kTLS, outro exige uma regra específica do ebtables configurada pelo administrador e o terceiro requer acesso local, embora estudos públicos sobre exploits já mostrem uma cadeia de escalonamento de privilégios contra um kernel visado. Essa é a parte tranquilizadora.

A lição está em tudo ao seu redor. Todas as três vulnerabilidades podiam ser corrigidas antes mesmo de a CISA se pronunciar, e a correção no código-fonte, os backports dos fornecedores, a implantação na frota e a exploração não ocorrem no mesmo cronograma. Enquanto isso, as pontuações em circulação indicavam às pessoas um nível de urgência equivocado, e uma solução alternativa anterior do fornecedor para um CVE, silenciosamente, não surtiu efeito nos kernels que deveria proteger. O prazo de três dias também expirou antes que a Red Hat tivesse lançado qualquer correção para o CVE-2025-39964; assim, o kernel do fornecedor simplesmente não estava disponível quando chegou a data federal de correção para esse problema específico.

Para frotas com patches convencionais, instale os kernels corrigidos e reinicie de acordo com um cronograma adequado, dando prioridade aos hosts com reescrita de ARP via ebtables e aos hosts kTLS. Para frotas em que a coordenação da reinicialização é o gargalo, o KernelCare fecha os caminhos cobertos no kernel em execução enquanto a manutenção normal continua.

Adquira o KernelCare hoje mesmo →

Linha do tempo

Referências

As fontes primárias para esta publicação são o catálogo de Vulnerabilidades Exploradas Conhecidas da CISA (versão 2026.10.01), o alerta da CISA de 18 de setembro de 2026, a Diretiva Operacional Vinculativa 26-04 e as páginas da Red Hat sobre os CVEs CVE-2025-39682, CVE-2026-53266 e CVE-2025-39964, as entradas do NVD para CVE-2025-39682, CVE-2026-53266 e CVE-2025-39964, e as correções do desenvolvedor original 62708b9452f8, 67ba971ae025 e 1b34cbbf4f01.