Vazamento expõe seis falhas críticas do kernel Linux sem patch

Um e-mail no endereço errado

Informações sobre pelo menos seis vulnerabilidades críticas do kernel Linux↳Linux34 conteúdosKali Linux em um Servidor VPS: como, quando e por que usar?DevSecOps · dez 2024Construindo um Windows Service ou Linux Daemon com Worker Service & .NET Core – Parte 2Dev (Back & Front) · jul 2020Criando uma WebApi utilizando .NET, Linux e VSCodeDev (Back & Front) · ago 2019Ver tudo em DevSecOps →, todas sem correção até o momento, vazaram publicamente por um erro de envio cometido por pesquisadores da Zero Day Initiative (ZDI), programa de caça a falhas mantido pela empresa de segurança Trend Micro, segundo reportagem publicada pelo CNews em 23 de outubro de 2026 com base em apuração do portal Neowin. O relatório, que deveria ir para o endereço de e-mail reservado e seguro da equipe de segurança do kernel, acabou incluído na Linux Kernel Mailing List (LKML), a lista de discussão pública usada por milhares de desenvolvedores do projeto.

O resultado: detalhes técnicos de falhas ainda não corrigidas ficaram expostos para qualquer pessoa com acesso à lista, inclusive quem quisesse explorá-las antes que exista patch.

Greg Kroah-Hartman, mantenedor do kernel estável e um dos braços direitos de Linus Torvalds na manutenção do projeto, reagiu com irritação ao vazamento, de acordo com o Neowin. Ele cobrou publicamente que os responsáveis pelo relatório corrijam o processo de envio e parem de mandar informações sobre falhas não corrigidas para endereços públicos. A reação negativa não ficou restrita à liderança: outros participantes da comunidade também criticaram o episódio.

O que vazou

A fonte lista ao menos seis identificadores da ZDI, todos classificados como críticos (CVSS 9.0 ou acima):

A mais grave do lote, ZDI-CAN-33774, atinge o KSMBD, implementação do protocolo SMB3 dentro do próprio kernel, e permite a um atacante remoto executar código arbitrário na máquina alvo. A segunda, ZDI-CAN-33549, tem a mesma gravidade (execução remota de código) e já conta com correção em uma branch do Git destinada à versão 7.5 do kernel, o que sugere que sua chegada à branch principal deve ser priorizada.

As duas últimas da lista, ZDI-CAN-34076 e ZDI-CAN-32005, nem sequer têm um CVE formal atribuído. Isso não é falha de burocracia: pelas regras da comunidade Linux, o identificador CVE só é emitido depois que o patch correspondente entra em uma versão estável do kernel, o que, neste caso, ainda não aconteceu.

Como o processo deveria ter funcionado

Em resumo: o modelo de divulgação responsável do kernel Linux prevê um caminho fechado entre quem encontra a falha e quem a corrige, com publicação só no fim da linha. O fluxo normal segue três etapas:

1. O pesquisador que encontra a falha envia um relatório privado à equipe de segurança do kernel;
2. Essa equipe desenvolve e testa a correção internamente, em builds de teste, antes de qualquer divulgação;
3. O patch é incorporado a uma versão estável do kernel e só então a vulnerabilidade pode ser tornada pública, já com CVE atribuído e correção disponível.

O vazamento rompeu esse fluxo no pior ponto possível: a etapa 3 (divulgação) aconteceu antes de a etapa 2 ser concluída (correção e teste). Na prática, qualquer pessoa com acesso à LKML passou a saber da existência e dos detalhes técnicos de falhas que ainda não têm defesa oficial.

Quem corre risco de verdade

Nem todo sistema Linux está exposto da mesma forma. Segundo o portal HWBusters, citado pelo CNews, estações de trabalho comuns e PCs com Linux dificilmente são o alvo principal: o módulo KSMBD, onde está a falha mais grave, não vem habilitado por padrão na maioria das distribuições, e máquinas de uso pessoal normalmente não compartilham arquivos via SMB através do kernel.

O risco concentra-se em outro perfil de equipamento:

• NAS (servidores de armazenamento em rede) que usam KSMBD por ele ser mais rápido que implementações de SMB em espaço de usuário;
• Servidores domésticos ou de pequena empresa configurados para compartilhamento de arquivos via SMB;
• Qualquer máquina com a porta 445 (porta padrão do protocolo SMB) acessível a partir de uma rede não confiável, incluindo a internet pública.

Para esse grupo, a recomendação da própria fonte é tratar o equipamento como vulnerável até que uma versão corrigida do kernel esteja disponível, não apenas monitorar a situação.

O que fazer enquanto não existe patch estável

Como nenhuma das seis falhas tem correção definitiva até a publicação desta matéria, a mitigação é operacional, não de atualização. Duas medidas, citadas pela fonte, reduzem a exposição:

• Descarregar o módulo KSMBD se o serviço SMB via kernel não for essencial no equipamento;
• Bloquear o acesso à porta 445 por firewall para qualquer origem que não seja explicitamente confiável.

Para times de infraestrutura que mantêm NAS ou servidores de arquivos Linux em produção no Brasil, o primeiro passo é mapear onde o KSMBD está em uso, já que, diferente de um daemon em espaço de usuário, ele roda dentro do próprio kernel e seu comprometimento tende a ter impacto mais profundo no sistema. Verificar se o módulo está carregado e desativá-lo, quando não houver dependência direta dele, é uma medida de contenção mais confiável do que esperar o próximo release do kernel.

O que ainda está em aberto

A fonte não informa prazo para que as correções cheguem a uma versão estável do kernel, nem se alguma das seis falhas já está sendo explorada ativamente desde o vazamento. Também não há, até o momento, CVE formal para duas das seis vulnerabilidades (ZDI-CAN-34076 e ZDI-CAN-32005, ambas sem detalhamento técnico divulgado), o que dificulta o rastreamento automatizado por ferramentas de gestão de vulnerabilidades que dependem desse identificador. Enquanto isso não muda, acompanhar as listas de segurança do kernel e os changelogs de distribuições que usam KSMBD é a única forma de saber quando o risco for efetivamente encerrado.

Fonte: CNews (Rússia)