
Neste artigo (5)
Falhas de RCE no KSMBD do Linux: análise da exposição pela Cyber Kendra
Principais conclusões
- Verifique se hosts Linux executam KSMBD antes de presumir que seu inventário do Samba cobre a exposição SMB.
- Restrinja a porta 445 e revise SMB Direct, RDMA e compartilhamentos KSMBD graváveis enquanto as correções estão pendentes.
- Acompanhe as correções do kernel e a atribuição de CVE, pois a divulgação pública pode chegar antes que os fluxos de trabalho de correção estejam prontos.
Por que importa
- ProdutoProduct leaders should know whether file sharing depends on kernel SMB paths before customers ask for exposure answers.
- InvestidoresInvestors should read unpatched disclosure events as tests of asset visibility, response discipline, and infrastructure maturity.
Uma divulgação pública antes das correções oficiais transforma o KSMBD em uma lição sobre descoberta de ativos, exposição da porta 445 e controles compensatórios tranquilos.
Uma divulgação pública antes das correções principais transforma o KSMBD em uma lição sobre descoberta de ativos, exposição da porta 445 e controles compensatórios tranquilos.
Listas públicas de e-mail do kernel são onde o trabalho do Linux acontece. Elas ficam menos charmosas quando detalhes de execução remota de código ainda sem correção entram circulando com crachá de visitante e perguntando quem é responsável pela exposição de SMB. As divulgações do KSMBD são sérias, mas a lição mais útil é operacional: equipes não conseguem reduzir o risco de um serviço que não sabem que está em execução. Em algum lugar, uma planilha de inventário de ativos acabou de sentir um vento gelado.
O que o Threat Landscape diz que realmente se tornou público
Segundo o Threat Landscape Blog, a Zero Day Initiative da Trend Micro divulgou dois problemas críticos de execução remota de código no servidor SMB KSMBD do kernel Linux em listas públicas de e-mail do kernel nos dias 21 e 22 de outubro de 2026. Os problemas são rastreados como ZDI-CAN-33774 e ZDI-CAN-33549, e o Threat Landscape Blog informou que ambos têm pontuação CVSS 9,0. Essa pontuação não é um filme de terror, mas costuma entrar na sala com iluminação dramática e uma reunião de correção muito específica marcada.
O Threat Landscape Blog também informou que, em 22 de outubro de 2026, nenhum dos problemas tinha uma correção no kernel mainline e nenhum identificador CVE havia sido atribuído. A mesma fonte disse que o projeto do kernel atribui CVEs apenas depois que existe uma correção na árvore estável, que é o tipo de detalhe de processo que importa quando executivos perguntam por que não há um número CVE arrumadinho para colar no chamado. A gestão de vulnerabilidades adora identificadores. A realidade às vezes aparece antes de a impressora de etiquetas esquentar.
Por que o Cybersecurity News diz que esta não é uma história sobre Samba
O Cybersecurity News descreve o KSMBD como um servidor de arquivos SMB opcional integrado ao kernel Linux, separado do Samba. Essa distinção importa porque muitas organizações sabem onde o Samba está instalado, documentado e mantido a contragosto, enquanto a configuração do kernel costuma morar em outro arquivo mental. Se seu inventário de SMB significa apenas Samba, talvez você esteja olhando para o encanamento errado enquanto o teto pinga.
O Threat Landscape Blog acrescenta uma cláusula importante para acalmar os ânimos: o KSMBD não é habilitado por padrão em grandes distribuições, como o Red Hat Enterprise Linux. No entanto, ele pode ser carregado como módulo ou compilado em kernels personalizados, segundo a mesma fonte. Tradução: isso não é motivo para entrar em pânico com todos os hosts Linux, mas é um ótimo motivo para perguntar se appliances, sistemas de armazenamento, builds embarcados, kernels de laboratório ou imagens personalizadas dependem silenciosamente do SMB dentro do kernel.
Como o Threat Landscape diz que a exposição se parece
O Threat Landscape Blog informou que o ZDI-CAN-33774 não exige autenticação e afeta servidores executando KSMBD na porta 445. Esse é o padrão de exposição de que defensores não gostam, porque reduz o arco do personagem do agente de ameaça a um monólogo curto: encontrar serviço acessível, enviar tráfego, torcer para o bug se comportar. O controle prático não é glamoroso, que é como você sabe que talvez funcione: saiba onde a porta 445 está acessível e limite-a às redes que realmente precisam dela.
A segunda falha, ZDI-CAN-33549, tem um formato mais estreito. O Threat Landscape Blog disse que a exploração exige uma interface de rede compatível com RDMA, seja hardware ou o driver de software rxe, além de um compartilhamento KSMBD gravável e negociação SMB Direct. O Cybersecurity News também informou que o problema envolve SMB Direct, que usa rede RDMA, portanto a exposição depende da configuração e de esse recurso estar em uso. Em outras palavras, o raio de impacto não inclui toda máquina Linux, mas as máquinas no escopo são exatamente o tipo que merece verificação cuidadosa, entediante e linda.
O que o Cybersecurity News diz que a divulgação ensina
O Cybersecurity News informou que Greg Kroah-Hartman, mantenedor do kernel Linux, questionou por que algumas submissões foram enviadas para a lista pública sem patches. O veículo também disse que a ZDI não havia explicado publicamente o encaminhamento até 23 de outubro de 2026, então ainda não estava claro se isso foi um simples erro. Essa incerteza não é combustível para fofoca. É um lembrete de que fluxos de divulgação fazem parte do limite de segurança, e às vezes esse limite tem convite no calendário, mas não tem guardrail.
Para defensores, o momento da divulgação é a parte desconfortável. Quando detalhes técnicos chegam antes de uma correção no mainline, o trabalho muda de gerenciamento de patches para gerenciamento de exposição. Isso significa verificar se o KSMBD está presente, se está ativo, se a porta 445 está acessível, se existem compartilhamentos graváveis e se caminhos SMB Direct ou RDMA estão disponíveis. Nada disso é cinematográfico, mas também não é explicar depois do fato que ninguém sabia que o kernel estava servindo arquivos.
O que isso realmente significa para você
Com base nas reportagens do Threat Landscape Blog e do Cybersecurity News, o primeiro passo é inventário, não pânico. Confirme se algum sistema Linux executa KSMBD, especialmente onde existam kernels personalizados, módulos, cargas de trabalho de armazenamento ou implantações no estilo appliance. Depois reduza a acessibilidade em torno da porta 445, revise compartilhamentos KSMBD graváveis e dê atenção especial a ambientes que usam SMB Direct ou RDMA. Continue acompanhando correções no mainline e a atribuição de CVE, porque a história do patch ainda é a parte que todos querem ler por último, mas precisam acompanhar primeiro.
A lição para o futuro é maior do que essas duas descobertas. A superfície de ataque do kernel continua se expandindo porque recursos úteis seguem se aproximando do núcleo, e cada conveniência vira a futura revisão de incidente de alguém se ninguém for responsável por ela. Trate o KSMBD como um estudo de caso: saiba quais protocolos estão expostos, saiba qual implementação os fornece e tenha um plano de controles compensatórios para as horas incômodas entre a divulgação pública e as correções disponíveis. Segurança não é nunca ser surpreendido. É ser surpreendido com um mapa.
Fontes2 fontes
As reportagens, anúncios e pesquisas com que o editor de IA trabalhou. Os links abrem a publicação original.