Relatórios vazados do kernel do Linux incluem dois bugs no ksmbd e uma vulnerabilidade de root que contorna a correção “Dirty Frag”

A versão resumida

Ir para a versão completa ↓

O que aconteceu: Nos dias 20 e 21 de outubro de 2026 (UTC), a Zero Day Initiative (ZDI) da Trend Micro enviou seis relatórios de vulnerabilidade à equipe de segurança do kernel e, por engano, a listas de discussão públicas, incluindo a LKML e a netdev. Cinco deles são bugs do kernel e um está no ConnMan, um gerenciador de rede do espaço do usuário. Nenhum veio acompanhado de um patch, nenhum possui um CVE ainda, e três incluíram o código-fonte completo do PoC. O Phoronix publicou uma matéria sobre o assunto em 22 de outubro. Ir para esta seção →

O que importa: oZDI-CAN-33367 é uma falha no auxiliar de rede skb_zerocopy que permite que um usuário local sem privilégios grave no cache de páginas de um arquivo que ele só pode ler. Da mesma classe que o Dirty Pipe e a um passo de obter privilégios de root. A TuxCare reproduziu a falha internamente, obtendo um shell de root; ela contorna a correção de maio para o Dirty Frag (CVE-2026-43284) e, quando os relatórios vieram a público, nenhuma correção havia sido incorporada ao código-fonte original nem incluída no kernel de nenhuma distribuição. Portanto, essa falha foi realmente um zero-day. Ir para esta seção →

Quem está afetado: Nos testes da TuxCare, a exploração conseguiu acesso root no AlmaLinux 8, 9 e 10, no CloudLinux 9 e 10, no Debian 12 e 13 e no Ubuntu 24.04 e 26.04, contornando a restrição do AppArmor do Ubuntu no processo. Os kernels do CentOS 6 e 7 não estão vulneráveis. O CloudLinux 8, que compila todos os módulos necessários para a exploração, e o Ubuntu 22.04 ainda não foram testados. Ir para esta seção →

E quanto às pontuações de 9,0 ksmbd: ambas exigem que o servidor SMB integrado ao kernel esteja em execução, e ele permanece desativado a menos que um administrador o configure deliberadamente. Os PoCs públicos mostram um vazamento de memória no heap do kernel e travamentos, em vez de execução de código, embora isso não descarte a possibilidade de consequências mais graves. Ir para esta seção →

Situação atual: ainda não há um CVE para o ZDI-CAN-33367. A correção do upstream foi aceita na árvore de rede do kernel, mas ainda não chegou à linha principal. O AlmaLinux 9 já foi lançado com um kernel corrigido, enquanto o AlmaLinux 10 ainda não. O patch sem reinicialização da KernelCare já está disponível para o EL10 e o EL9; a versão para o EL8 está pronta para lançamento; e os trabalhos para o Debian e o Ubuntu estão em andamento. Até 27 de outubro, não foram relatados casos de exploração na natureza. Ir para esta seção →

O que fazer hoje: Verifique se os espaços de nomes de usuários sem privilégios estão ativados e desative-os nos hosts que não precisam deles. A 0 Isso significa que não é possível criar novos espaços de nomes de usuário, o que deve impedir o PoC público:

sysctl user.max_user_namespaces

Ir para esta seção →

Falhas de escalonamento de privilégios locais costumam ser classificadas como um problema para a próxima semana. O raciocínio é o seguinte: primeiro, alguém precisa de um shell; e, se já tiver um, você tem problemas maiores.

Essa lógica não se sustenta nos servidores em que o KernelCare costuma ser executado. Um servidor de hospedagem compartilhada com 300 contas cPanel possui, por padrão, 300 usuários locais, e cada um deles pode executar PHP ou uma tarefa cron. Um executor CI executa tudo o que uma solicitação pull (pull request) lhe instruir. Um nó de login de universidade existe para fornecer shells. Em todos esses casos, “usuário local” significa simplesmente “cliente” ou “tarefa”, e uma gravação válida no cache de páginas pode conceder privilégios de root a qualquer um deles.

Esse é o problema com o ZDI-CAN-33367. O relatório, a análise e o código-fonte da demonstração de conceito (PoC) chegaram às listas públicas do kernel antes mesmo de haver uma correção. Normalmente, o patch é lançado primeiro e os detalhes vêm em seguida. Desta vez, aconteceu o contrário.

O próprio guia do kernel para relatar falhas de segurança pede que os relatores enviem as informações de forma privada aos mantenedores dos subsistemas e à equipe de segurança do kernel, e não a uma lista pública, além de não divulgarem nenhum código de reprodução. Dessa forma, uma correção pode estar pronta antes que qualquer outra pessoa veja os detalhes. O ZDI normalmente funciona da mesma maneira. Sua política de divulgação concede aos fornecedores 120 dias para lançar um patch antes que os detalhes sejam tornados públicos, e sua lista de alertas futuros indica o prazo de 18 de fevereiro de 2027 para os cinco relatórios relacionados ao kernel.

O relatório sobre o ConnMan chegou primeiro à lista pública do ConnMan, às 00h17 UTC do dia 20 de outubro. A própria lista da ZDI indica a data de 19 de outubro, que é quando ele foi enviado no horário dos EUA. Os cinco relatórios do kernel, incluindo o ZDI-CAN-33367, vieram em seguida, na noite de 21 de outubro (UTC), com cópias enviadas à equipe de segurança do kernel e também às listas LKML, netdev, linux-cifs, dri-devel e linux-nvme. Greg Kroah-Hartman e outros mantenedores responderam que os relatórios já estavam públicos e haviam chegado sem patches. Três dos seis incluem uma descrição completa e o código-fonte completo do PoC. Dois relatórios do kernel não têm nada público além do título, e o último nem sequer é um bug do kernel.

Por mais estranho que pareça, a vulnerabilidade com a pontuação mais baixa do kernel na lista é justamente aquela à qual este post dedica mais tempo. A pontuação base do CVSS descreve a falha em si. Ela não reflete se já existe um código de exploração funcional disponível publicamente, e no caso do ZDI-CAN-33367, esse código já está disponível. Em sistemas onde os pré-requisitos para a exploração estão presentes, isso é mais importante do que um ou dois pontos na pontuação.

Nenhuma dessas vulnerabilidades possui um CVE ainda. Isso pode parecer apenas uma questão burocrática, mas muitos scanners e painéis de gerenciamento de patches se baseiam exclusivamente nos IDs do CVE; portanto, esses relatórios podem nem aparecer nessas ferramentas por enquanto. É recomendável complementar suas ferramentas habituais com verificações manuais e atualizações dos fornecedores até que os IDs sejam atribuídos.

skb_zerocopy() transfere dados de pacotes entre buffers de soquete passando referências às mesmas páginas de memória, em vez de copiar bytes. Isso é ótimo para a taxa de transferência. É também o tipo de atalho que sempre aparece em bugs do cache de páginas, nos quais uma referência a uma página que pertence a um arquivo acaba em algum lugar onde pode ser gravada.

O Dirty Pipe conseguiu isso por meio de canais em 2022. O Copy Fail conseguiu isso por meio do soquete de criptografia AF_ALG em abril de 2026. Em maio, o Dirty Frag (CVE-2026-43284) conseguiu isso por meio do ESP, a camada IPsec, que descriptografava pacotes no local mesmo quando suas páginas pertenciam a um arquivo. O ZDI-CAN-33367 é uma continuação desse último.

A correção do “Dirty Frag” adicionou uma proteção. Quando os dados do pacote provêm de páginas que não pertencem exclusivamente ao kernel, eles são marcados com um sinalizador chamado SKBFL_SHARED_FRAG, e o ESP verifica esse sinalizador e faz uma cópia privada antes de descriptografar. skb_zerocopy() transfere essas mesmas páginas para um novo buffer, mas não repassa o sinalizador. A proteção nunca é acionada, o ESP é descriptografado no próprio local e a gravação é armazenada no cache de páginas de um arquivo que o invasor só pode ler. O erro subjacente remonta ao comando `commit` af2806f8f90a, que introduziu skb_zerocopy() no kernel 3.14.

Isso traz uma consequência incômoda. O AlmaLinux 8, 9 e 10 vêm com a correção do “Dirty Frag”, conforme confirmado pela TuxCare nos registros de alterações do kernel do AlmaLinux, e, mesmo assim, continuam vulneráveis. Um painel de patches que mostra o CVE-2026-43284 como resolvido não diz nada sobre esse bug.

Assim como no “Dirty Pipe”, trata-se de uma gravação pura no cache de página. Os processos que leem ou executam o arquivo posteriormente recebem a versão do invasor; e, nos casos do “Dirty Pipe” e do “Copy Fail”, essas alterações nunca chegaram ao arquivo no disco, o que dificultou a análise forense. Direcione-o para um binário setuid ou /etc/passwd e o acesso como root está a um passo de distância. A exploração não precisa de nenhum recurso especial nem de um vazamento de KASLR para chegar lá.

A demonstração de conceito (PoC) publicada apresenta uma lista específica de requisitos. Ela requer espaços de nome de usuário sem privilégios, que são a forma usual pela qual um processo sem privilégios obtém direitos de administrador de rede dentro de sua própria sandbox. Além disso, ela depende de módulos que são carregados automaticamente sob demanda: nfnetlink_queue, nft_queue, nlmon, cls_u32, act_pedit, act_mirred e esp4, além dos módulos de criptografia por trás de uma cifra ESP que não utiliza AEAD. O kernel 6.1 do Debian 12 requer um caminho ligeiramente diferente para inserir páginas de arquivo em um pacote, mas a exploração ainda funciona nesse caso. Essa lista descreve a exploração divulgada publicamente, e não todas as vias possíveis para o bug, mas é o que torna a mitigação possível, e isso será abordado mais adiante.

O mantenedor do Netdev, Eric Dumazet, respondeu ao relatório informando que outra fonte havia enviado o mesmo bug, acompanhado de um patch, uma semana antes, e que a correção estaria disponível em breve. Em 22 de outubro, esse patch foi publicado no Netdev. Trata-se de uma alteração de uma linha que faz com que a função skb_zerocopy() copie o sinalizador de página compartilhada, e foi encaminhado em cópia à equipe do ramo estável.  Desde então, ela foi aceita na árvore de rede como o commit `79dc34beb1fd`, mas ainda não chegou à linha principal. De qualquer forma, uma correção na árvore de um mantenedor não indica quando os kernels corrigidos chegarão aos seus hosts. Uma correção do upstream ainda precisa se tornar um kernel de distribuição, depois um pacote e, por fim, um patch que exija ou não reinicialização em todos os servidores expostos — e o PoC já está disponível em um arquivo público.

A TuxCare recompilou o PoC público para cada alvo listado abaixo e o executou. “Root verificado” significa que a execução terminou com um shell com uid 0.

As duas versões mais antigas são seguras por motivos diferentes. O kernel 2.6.32 do CentOS 6 é anterior a skb_zerocopy() totalmente, portanto não há nada que possa ser explorado. O kernel 3.10 do CentOS 7 possui essa funcionalidade, mas seu código ESP sempre cria uma cópia privada dos pacotes não lineares antes de descriptografá-los. O atalho “in-place” chegou ao código-fonte original na versão 4.11 e nunca foi incorporado ao EL7; além disso, os namespaces de usuários sem privilégios estão desativados por padrão nesse sistema.

Ainda não foram testados o Ubuntu 22.04 e algumas linhas de kernel distintas, incluindo os kernels EL e ELS, os kernels AlmaLinux ESU e FIPS, o Oracle UEK, os kernels cloud e HWE, e o kernel do CloudLinux 7. O CloudLinux 8 também não foi testado, mas seu kernel compila todos os módulos necessários para a exploração pública. Os kernels corrigidos do CloudLinux 7h e 8 (4.18.0-553.177.1.lve.1) estão em fase beta. Considere todos eles como possivelmente afetados até que tenham sido verificados.

O Ubuntu 24.04 e versões posteriores aplicam restrições do AppArmor aos espaços de nome de usuários sem privilégios, controlados por kernel.apparmor_restrict_unprivileged_userns. Isso não impediu essa exploração. O PoC contorna essa restrição executando-se por meio do perfil do AppArmor de um pacote iniciador de contêineres que tem permissão para criar espaços de nome de usuário. Não considere isso uma medida de mitigação.

O ZDI atribuiu a ambos os relatórios do ksmbd uma pontuação de 9,0 e os classificou como falhas de execução remota de código, o que fez com que ganhassem destaque nas manchetes. Os PoCs públicos demonstram a divulgação de memória do kernel e travamentos, em vez de execução de código. Esses são problemas de segurança reais por si só, e os resultados publicados não mostram toda a extensão do que um invasor poderia fazer. O ZDI também identifica um caminho de gravação fora dos limites para o ZDI-CAN-33774 que não é mostrado no material público.

O que limita os danos é a exposição. Ambas as falhas estão presentes no ksmbd, o servidor SMB integrado ao kernel. Isso é diferente do Samba, o servidor SMB do espaço do usuário executado pela maioria dos servidores de arquivos Linux, e os servidores que compartilham arquivos exclusivamente por meio do Samba não estão expostos a essas falhas.

O AlmaLinux e o CloudLinux 9 e 10 nem sequer compilam o ksmbd. O Debian e o Ubuntu o compilam, mas como uma opção opcional. Ele só é executado depois que um administrador o instala ksmbd-tools, que não vem por padrão, e inicia o ksmbd serviço. O ZDI-CAN-33549 acrescenta mais condições. É necessário o SMB Direct em um dispositivo de rede RDMA e um compartilhamento gravável acessível por meio de login ou acesso de convidado. O Ubuntu inclui o SMB Direct, o Debian não, e o hardware RDMA é raro em servidores de hospedagem.

Se você estiver executando o ksmbd, leve a sério a vulnerabilidade ZDI-CAN-33774. Ela pode ser explorada pela rede antes do login, vaza 28 bytes da pilha do kernel de cada vez e pode causar a falha do host. Namjae Jeon, mantenedor do ksmbd respondeu que já está registrado na árvore dele como confirmar 68f410faedaf, que ainda não chegou ao ramo principal. Se systemctl is-active ksmbd indica que está inativo e lsmod não inclui ksmbd, isso é um bom indício de que o servidor não está em execução, mas confirme se nenhum outro processo no host o iniciou antes de descartar essa possibilidade. Se ele estiver ativo e nada depender do compartilhamento, interrompa-o com systemctl disable --now ksmbd. Se for necessário usar o compartilhamento, mantenha-o fora de redes não confiáveis até que sejam disponibilizados kernels corrigidos.

O resto da pilha

ZDI-CAN-34068 é uma gravação fora dos limites no vmwgfx, o driver da GPU virtual da VMware, classificada como escalada de privilégios local. ZDI-CAN-34076 é um vazamento de memória não inicializada no nvmet, o destino do NVMe over Fabrics. Ambos foram divulgados publicamente apenas com os títulos. Sem detalhes técnicos, não há nada concreto a ser verificado ou mitigado; portanto, nenhuma ação está prevista até que mais informações sejam divulgadas.

O ZDI-CAN-32005 está presente no ConnMan, um gerenciador de rede no espaço do usuário. Não se trata de um bug do kernel, portanto, está fora do escopo das correções do KernelCare. Se você utiliza o ConnMan, fique atento às atualizações por meio dos canais habituais de pacotes.

Nenhuma das medidas de mitigação abaixo foi validada internamente em relação ao PoC até o momento. Teste cada uma delas primeiro em um servidor de teste para identificar quais componentes dependem delas e não considere nenhuma delas como substituto de uma correção definitiva.

A principal opção é desativar os espaços de nomes de usuários sem privilégios. Configuração user.max_user_namespaces para 0 impede a criação de novos espaços de nomes de usuário, o que deve bloquear o PoC público, já que ele depende da criação de um. Ao contrário da restrição do AppArmor do Ubuntu, trata-se de um limite rígido do kernel que nenhum perfil do AppArmor consegue contornar:

echo 'user.max_user_namespaces = 0' > /etc/sysctl.d/99-zdi-33367.conf
sysctl --system

Os namespaces que já existem permanecem como estão, de modo que tudo o que já estiver em execução dentro deles continua funcionando. O custo também é real. Contêineres sem raiz, aplicativos Flatpak e algumas sandboxes de navegadores dependem de namespaces de usuário e podem deixar de funcionar.

A opção mais leve desativa dois dos módulos menos comuns dos quais o PoC público depende, nlmon e act_pedit, ao ser carregado por meio do mecanismo normal do módulo:

printf 'install nlmon /bin/false\ninstall act_pedit /bin/false\n' > /etc/modprobe.d/zdi-33367.conf
lsmod | grep -E '^(nlmon|act_pedit) '

O lsmod Essa linha apenas indica se algum dos módulos está carregado no momento. Se algum deles aparecer, a nova regra não o descarregará. Verifique se nada depende dele e, em seguida, descarregue esse módulo com modprobe -r, ou agende uma reinicialização. No entanto, um resultado vazio não é prova de que o bloco esteja no lugar. Execute modprobe -n -v nlmon e modprobe -n -v act_pedit, e confirme se ambos imprimem o install /bin/false linha. Isso confirma a configuração do módulo, e não que a vulnerabilidade tenha sido bloqueada. Poucos servidores usam nlmon ou o pedit ação em tc, mas verifique antes de tirar conclusões precipitadas. Bloquear esses dois também pode não cobrir todas as possibilidades que levam ao bug. Tudo o que se sabe é que o PoC público precisa deles. O PoC precisa esp4 também; portanto, se um servidor não usar o IPsec e você tiver bloqueado esp4 Para o Dirty Frag, lá em maio, verifique se o bloco ainda está no lugar.

Desativar os namespaces de usuário é a principal opção; portanto, comece por aí em qualquer host que possa funcionar sem eles. Verifique primeiro o que está em execução no servidor. Em servidores de hospedagem web, de e-mail, de banco de dados e compartilhados, isso geralmente é viável, desde que nada neles utilize contêineres sem privilégios de root ou sandboxing. Em executores de CI, servidores de compilação e estações de trabalho de desenvolvedores que dependem de namespaces de usuário, bloquear os dois módulos é uma solução alternativa menos disruptiva, mas pode deixar outras vias de acesso ao bug abertas. Coloque esses servidores em primeiro lugar na fila quando for lançado um patch que não exija reinicialização.

Verificando um servidor em menos de um minuto

Três comandos respondem à maioria das perguntas:

sysctl user.max_user_namespaces
systemctl is-active ksmbd
lsmod | grep -E '^(ksmbd|nlmon|act_pedit) '

A 0 A partir da primeira versão, os novos espaços de nomes de usuário estão desativados, o que deve bloquear o caminho da vulnerabilidade divulgada publicamente. inactive A segunda linha sugere que o ksmbd não está em execução, e a terceira confirma se o ksmbd o módulo ou qualquer um dos dois módulos bloqueáveis está carregado no momento. No Ubuntu 24.04 e versões posteriores, não dê muita importância a sysctl kernel.apparmor_restrict_unprivileged_userns. O PoC superou essa restrição nos testes. Esses são indicadores rápidos, não um teste de segurança completo. Para uma frota, execute as mesmas linhas por meio do que já lida com seus comandos ad hoc, seja o Ansible, o Salt ou o ssh simples em um loop.

O patch sem reinicialização da KernelCare para o ZDI-CAN-33367 já está disponível para os kernels EL10 e EL9 no AlmaLinux, CloudLinux, RHEL, Oracle Linux e Rocky Linux. Ele foi desenvolvido com base na versão candidata à correção do upstream, e a TuxCare verificou que ele bloqueia a exploração pública. O patch para o EL10 está disponível tanto no feed de produção quanto no ePortal. O patch para o EL9 está no feed de produção, mas ainda não no ePortal. O patch para o EL8 está pronto para lançamento, e o trabalho para o Debian e o Ubuntu está em andamento, sem data definida ainda. Os kernels EL6 e EL7 não são vulneráveis, portanto não receberão um patch sem reinicialização para esse bug.

Nas versões EL9 e EL10, os hosts com atualizações automáticas do KernelCare recebem o patch de acordo com sua programação normal; caso contrário, você pode baixá-lo imediatamente usando o comando `kcarectl –update`. Não é necessário reiniciar o sistema, o que é ainda mais importante do que o habitual neste caso, já que o bloqueio de módulos mencionado acima pode exigir uma reinicialização. Como não há IDs de CVE atribuídos, o TuxCare CVE Tracker não apresenta nada sobre esses relatórios hoje. Assim que os IDs forem atribuídos, é lá que aparecerá o status do patch sem necessidade de reinicialização para cada distribuição.

Adquira o KernelCare Enterprise hoje mesmo →

Por que um vazamento como esse muda o cronograma

A divulgação coordenada existe para dar aos defensores uma vantagem inicial, e, nesta semana, essa vantagem foi nula.

No âmbito da divulgação coordenada, os mantenedores e as distribuições geralmente têm tempo para preparar correções antes que os detalhes técnicos ou o código da exploração sejam divulgados publicamente. Nesse caso, a ordem se inverteu. Primeiro, a exploração em funcionamento; depois, a correção. Esse intervalo entre a divulgação pública da exploração e a aplicação do patch no host é exatamente o que todo processo de correção tenta manter curto e, no caso do ZDI-CAN-33367, ele se abriu antes que alguém pudesse agir.

A correção no upstream não está longe e já está na árvore de rede. Outra pessoa encontrou esse bug uma semana antes e enviou um patch, o que mostra quantas pessoas estão analisando o mesmo código do kernel neste momento. É de se esperar mais coincidências como essa e mais bugs que venham a público antes que um kernel estável inclua a correção.

Portanto, verifique hoje mesmo os namespaces de usuário e desative-os sempre que não forem necessários. Descubra se alguém ativou o ksmbd e se esqueceu disso. Em seguida, fique atento para que essa correção chegue aos kernels da sua distribuição e avalie com que rapidez você pode aplicá-la em todos os hosts expostos — seja por meio de um patch sem reinicialização ou por reinicialização, dependendo do que sua infraestrutura realmente tolerar.

Adquira o KernelCare Enterprise hoje mesmo →

Como foi a semana

Fontes

As fontes primárias para esta publicação são os relatórios originais da ZDI e as respostas dos mantenedores nas listas de discussão públicas, incluindo o relatório ZDI-CAN-33367, a resposta de Eric Dumazet, o patch skb_zerocopy, o tópico ZDI-CAN-33774, o commit da correção do ksmbd e o relatório do ConnMan, além da lista de alertas futuros da ZDI, a cobertura do Phoronix, o guia de denúncia de falhas de segurança do kernel, a política de divulgação da ZDI, a documentação do ksmbd do kernel, o artigo “Dirty Pipe” de Max Kellermann, a divulgação do “Copy Fail”, a entrada do NVD para “Dirty Frag” e os próprios testes da TuxCare nas distribuições listadas acima.