Nova falha DirtyClone no Linux: o que é, por que é grave e como se proteger
Uma nova vulnerabilidade de escalonamento de privilégios locais no kernel Linux, batizada de “DirtyClone” (CVE-2026-43503), abriu mais uma porta para que usuários sem privilégios consigam acesso root completo. O problema explora a forma como o sistema lida com pacotes de rede clonados no subsistema XFRM/IPsec, permitindo que a memória seja manipulada sem gerar alertas em logs do kernel ou em mecanismos de auditoria.
De onde vem o DirtyClone e a família DirtyFrag
DirtyClone é uma variante de alta gravidade da família de vulnerabilidades DirtyFrag – um conjunto de falhas de corrupção de memória no kernel que afeta a maneira como os buffers de soquete (skb) fazem referência à memória de página compartilhada em cache.
DirtyFrag, Fragnesia e DirtyClone não formam uma cadeia de exploração, mas sim “irmãs” que compartilham a mesma base: a incapacidade do kernel de separar de forma rigorosa três tipos de uso de memória:
– cache de páginas baseadas em arquivos;
– buffers de rede (skb);
– transformações criptográficas realizadas “in-place” (no mesmo espaço de memória).
Esse compartilhamento indevido de memória entre diferentes funções abre espaço para que um atacante, com acesso local, modifique dados sensíveis e desvie a execução do sistema.
Descoberta e classificação da falha
A vulnerabilidade CVE-2026-43503 foi descoberta pela equipe de pesquisa de segurança da JFrog durante uma auditoria de patches do kernel que tratavam correções anteriores da DirtyFrag. Ela recebeu pontuação CVSS 8,8, sendo considerada de alta gravidade.
O problema foi reportado de forma independente em 19 de maio de 2026, quase ao mesmo tempo em que Hyunwoo Kim, pesquisador responsável pela identificação original da DirtyFrag, submeteu um relatório mais abrangente em 16 de maio. Isso reforça que a comunidade de pesquisa já desconfiava da existência de caminhos alternativos de exploração mesmo após as primeiras correções.
O ponto central: a função __pskb_copy_fclone()
O cerne da falha está na função interna do kernel __pskb_copy_fclone(). Essa função é usada para clonar buffers de rede (skbs). Durante esse processo, ela acaba descartando o sinalizador de segurança SKBFL_SHARED_FRAG – exatamente o marcador introduzido pela mitigação original do DirtyFrag para proteger a memória de páginas compartilhadas baseadas em arquivos.
Na prática, ao remover silenciosamente esse sinalizador, a função reabre a possibilidade de que a mesma região de memória seja reinterpretada de maneira insegura. Isso permite que o atacante construa um cenário no qual um arquivo em disco seja mapeado na memória e, por meio de operações de rede cuidadosamente manipuladas, essa memória compartilhada seja corrompida em benefício do invasor.
O que diferencia o DirtyClone das variantes anteriores
Enquanto o DirtyFrag explorava caminhos de “emenda” direta de pacotes, DirtyClone se vale de um fluxo distinto: ele ataca via um caminho de clonagem de pacotes, disparado especificamente pelo alvo TEE do netfilter do Linux.
Esse alvo TEE é responsável por duplicar internamente pacotes para que eles sejam enviados a múltiplos destinos (algo útil, por exemplo, em cenários de monitoração de tráfego ou balanceamento). Na hora de fazer essa duplicação, o kernel recorre à função __pskb_copy_fclone(), que, por sua vez, perde o sinalizador SKBFL_SHARED_FRAG.
Isso mostra que o problema não está apenas em um ponto específico do código, mas em qualquer caminho de cópia ou clonagem que mexa nos marcadores de fragmentos compartilhados sem mantê-los consistentes.
A primitiva de ataque: qualquer transformação que remova o marcador é perigosa
A principal conclusão da pesquisa é que o ataque não depende de um único fluxo de código. A primitiva de exploração é mais genérica: qualquer transformação de skb que remova o marcador de fragmento compartilhado (SKBFL_SHARED_FRAG) pode ser usada como vetor.
Ou seja, se existir qualquer rotina no kernel que:
1. trabalhe com buffers de rede (skbs) compartilhando memória;
2. descarte ou ignore o sinalizador de fragmento compartilhado;
3. permita que essa memória esteja ligada a conteúdo de arquivo em disco;
então um invasor pode, em teoria, construir um caminho para escalonar privilégios.
Fragnesia (CVE-2026-46300) e DirtyClone demonstram exatamente isso: mesmo após a primeira correção da DirtyFrag (CVE-2026-43284), ainda havia caminhos em que o sinalizador poderia ser removido de forma silenciosa.
Como o exploit atua e por que é tão difícil detectar
O exploit DirtyClone encadeia uma sequência de etapas (sete, segundo a pesquisa) para alcançar o acesso root. Embora os detalhes completos não tenham sido divulgados publicamente, a lógica geral segue a mesma linha de outras falhas de “dirty” no Linux:
– o atacante, com acesso a um usuário local sem privilégios, faz uso de funcionalidades legítimas do sistema (como namespaces de usuário e mecanismos de rede);
– cria uma situação em que um arquivo mapeado em memória e um pacote de rede compartilham a mesma área de página;
– explora a falha de validação do sinalizador SKBFL_SHARED_FRAG para modificar o conteúdo em memória;
– essa alteração impacta dados de controle do kernel ou binários críticos, permitindo a elevação de privilégios.
Um ponto crítico é que o arquivo em disco permanece intacto. Toda a manipulação ocorre apenas na memória, o que torna a ação praticamente invisível a:
– sistemas de monitoramento de integridade de arquivos;
– verificações tradicionais de auditoria do kernel;
– ferramentas de EDR que dependem fortemente de alterações em disco como indicador de ataque.
O resultado é um ataque “limpo” do ponto de vista de logs, aumentando drasticamente a dificuldade de detecção posterior.
Sistemas afetados e alcance da vulnerabilidade
A CVE-2026-43503 impacta uma gama ampla de distribuições Linux modernas em que namespaces de usuário sem privilégios estão habilitados. Esse recurso, muito utilizado em containers e ambientes isolados, permite que processos rodem com um conjunto de permissões independentes do usuário “real” do sistema, ampliando a superfície para escalonamento de privilégios em caso de falha no kernel.
Importante: qualquer kernel que não possua toda a cadeia de patches da família DirtyFrag continua vulnerável, mesmo que tenha aplicado apenas a correção original. Isso inclui:
– correção do DirtyFrag (CVE-2026-43284);
– correção do Fragnesia (CVE-2026-46300);
– correção do DirtyClone (CVE-2026-43503).
Sem a combinação completa de correções, ainda podem existir caminhos de código em que o sinalizador SKBFL_SHARED_FRAG não é devidamente preservado.
Estado das correções no kernel Linux
A correção para o DirtyClone foi incorporada ao kernel principal em 21 de maio de 2026 (commit 48f6a5356a33). A primeira versão oficial do kernel considerada corrigida é a v7.1-rc5, lançada em 24 de maio de 2026.
O patch não se limita a resolver apenas um trecho de código: ele tenta “propagar” a proteção por toda a classe de operações relevantes. Em outras palavras, o ajuste garante que:
– o sinalizador SKBFL_SHARED_FRAG seja mantido corretamente em todos os caminhos de cópia e clonagem de skb;
– operações de coalescência de pacotes respeitem o marcador;
– rotinas de recebimento GRO (Generic Receive Offload) preservem o estado correto;
– segmentações de pacotes não descarem informações de segurança.
A abordagem é mais holística justamente porque as vulnerabilidades anteriores mostraram que mitigar apenas um fluxo de código é insuficiente.
O papel dos namespaces de usuário e do XFRM/IPsec na exploração
Para entender por que essa falha é particularmente sensível, vale destacar dois componentes-chave:
1. Namespaces de usuário
Eles permitem que um usuário sem privilégios crie um ambiente isolado em que aparenta ter permissões mais elevadas dentro do namespace, ainda que não as tenha no sistema host. Em combinação com vulnerabilidades de kernel, esses namespaces funcionam como um “amplificador” do ataque, porque fornecem primitivos adicionais para manipular recursos do sistema sem exigir acesso root prévio.
2. Subsistema XFRM/IPsec
O XFRM é a camada do kernel responsável por transformar e processar pacotes, incluindo recursos de criptografia IPsec. Ao utilizar esse subsistema e caminhos específicos do netfilter, como o alvo TEE, o invasor consegue disparar rotinas internas de clonagem de pacotes que interagem diretamente com a memória de página compartilhada. É exatamente nesse ponto que o bug se manifesta.
A combinação desses dois elementos – mais funcionalidades de rede avançadas – cria um cenário ideal para exploração quando há falhas de isolamento de memória.
Riscos práticos para empresas e administradores
Embora o DirtyClone exija acesso local ao sistema, isso não o torna pouco relevante. Em ambientes corporativos e de nuvem, é comum que:
– existam múltiplos usuários com acesso SSH;
– workloads de terceiros sejam executadas em containers;
– aplicações SaaS sejam hospedadas em servidores Linux multi-tenant.
Em todos esses cenários, um usuário com credenciais limitadas – obtidas por phishing, ataque de força bruta ou falha em aplicação web – pode tentar explorar a vulnerabilidade para se tornar root e ganhar controle completo da máquina, escapar de containers ou acessar dados de outros clientes/usuários.
Adicionalmente, como o ataque praticamente não deixa rastros, a resposta a incidentes se torna mais complexa, dificultando a comprovação da linha do tempo do ataque e a identificação de que um escalonamento de privilégios foi, de fato, o vetor inicial.
Como mitigar e reduzir a superfície de ataque
As ações imediatas mais importantes incluem:
1. Atualizar o kernel
– Priorizar a instalação de versões que incluam a correção integrada para DirtyFrag, Fragnesia e DirtyClone.
– Em distribuições corporativas, aplicar os backports de segurança disponibilizados pelo fornecedor.
2. Revisar o uso de namespaces de usuário sem privilégios
– Onde não forem estritamente necessários, considerar desativá-los temporariamente ou restringir sua criação a determinados usuários ou serviços.
– Em ambientes de containers, verificar as opções de runtime para limitar privilégios, como uso de user namespaces mapeados com UID não privilegiado no host.
3. Endurecer a superfície de rede
– Avaliar se recursos como alvo TEE e configurações avançadas de netfilter/XFRM/IPsec são realmente necessários.
– Desabilitar módulos ou caminhos pouco utilizados reduz os vetores disponíveis a um atacante.
4. Segmentação e princípio do menor privilégio
– Minimizar a quantidade de usuários com acesso shell a servidores críticos.
– Utilizar bastions, MFA e controles de acesso rígidos para dificultar o primeiro passo do atacante (obter acesso local).
Detecção, monitoramento e resposta
Embora o ataque em si não altere arquivos em disco, ainda há possibilidades de aumentar a visibilidade:
– Monitoramento de criação de namespaces de usuário
Criar alertas para comportamentos incomuns, como criação massiva de namespaces por processos que normalmente não utilizam esse recurso.
– Análise de comportamento de processos
EDRs e soluções de observabilidade podem ajudar a detectar padrões atípicos, como processos não privilegiados realizando chamadas de sistema relacionadas a XFRM/IPsec e netfilter de forma intensa ou fora do padrão operacional.
– Revisão de logs de autenticação
Mesmo que o escalonamento não deixe rastro, o acesso inicial geralmente deixa: tentativas de login, uso suspeito de chaves SSH, falhas de autenticação ou logins de origens inusitadas.
– Testes de segurança e varredura de configuração
Incorporar checagens específicas em scanners internos para identificar kernels desatualizados e configurações de rede que ampliem a superfície de ataque.
Boas práticas de longo prazo
A família DirtyFrag – e agora o DirtyClone – reforça uma mensagem já conhecida, mas frequentemente negligenciada:
– Gestão de patches deve ser contínua e priorizada, especialmente em componentes de baixo nível como o kernel.
– Segurança de rede e criptografia não são apenas funções de “confidencialidade”, mas também pontos sensíveis de memória e processamento, que podem ser explorados se mal implementados.
– Isolamento de recursos (namespaces, containers, VMs) reduz riscos, mas não substitui a correção de falhas no host; vulnerabilidades de kernel tendem a “furar” várias camadas de isolamento.
Para empresas que operam grandes ambientes Linux, é recomendável:
– manter inventário atualizado de versões de kernel em produção;
– definir janelas de manutenção periódicas e bem comunicadas;
– simular incidentes de escalonamento de privilégios como parte de exercícios de Red Team ou testes de penetração.
—
Em resumo, DirtyClone é mais uma peça de uma família de vulnerabilidades que expõe fragilidades na forma como o kernel Linux compartilha memória entre subsistemas. Embora exija acesso local, o impacto potencial é crítico: um simples usuário sem privilégios pode se tornar root sem deixar praticamente nenhum vestígio. A única defesa consistente é combinar atualização rápida do kernel, endurecimento de configurações (especialmente de namespaces e rede) e monitoramento atento de comportamentos suspeitos.