DirtyClone (CVE-2026-43503): nova falha no kernel Linux permite escalada local para root via page cache

Resumo: A JFrog publicou detalhes técnicos e um proof-of-concept para a CVE-2026-43503, batizada de DirtyClone – uma falha de escalada local de privilégios no kernel Linux com pontuação CVSS 8.8. O bug é variante do DirtyFrag (Copy Fail 2) e do Fragnesia, corrigidos em meados de maio, e compartilha DNA com o histórico Dirty Pipe de 2022. Qualquer usuário local sem privilégios pode manipular o page cache e obter root.

O que aconteceu

A equipe de pesquisa da JFrog divulgou nesta semana um relatório técnico aprofundado sobre a CVE-2026-43503, uma vulnerabilidade no kernel Linux que permite a qualquer usuário local sem privilégios elevar permissões até root. A falha foi reportada aos mantenedores do kernel e corrigida em 24 de maio, mas só agora ganhou contornos públicos com PoC funcional.

A vulnerabilidade foi apelidada de DirtyClone e é classificada como variante de duas falhas anteriores – DirtyFrag (também conhecida como Copy Fail 2) e Fragnesia – resolvidas em maio. Todas pertencem à mesma família de bugs de corrupção de memória na stack de rede do kernel, com raízes em como os socket buffers (skb) compartilham referências para memória do page cache.

Para quem acompanha a história recente das vulnerabilidades do kernel Linux, o padrão é familiar: DirtyClone é o herdeiro do Dirty Pipe (CVE-2022-0847), divulgado em março de 2022 – mesma classe de bug que transformou simples leitores de arquivos em vetores de privilege escalation. A diferença é que, em 2026, o caminho de exploração agora passa por transformações criptográficas in-place em subsistemas de rede.

Detalhes da vulnerabilidade

O bug está nas estruturas de socket buffer (skb) – as unidades fundamentais que o kernel usa para mover pacotes de rede. Esses buffers podem referenciar páginas compartilhadas do page cache (a área de memória que mantém em cache o conteúdo de arquivos lidos do disco). Quando o kernel aplica uma transformação criptográfica “in-place” em um buffer – como criptografar ou descriptografar bytes diretamente sobre a página, sem cópia intermediária – a operação acaba escrevendo na própria página de cache, em vez de em uma cópia privada.

O resultado é que dados controlados pelo atacante (o payload da operação criptográfica) sobrescrevem o conteúdo cacheado de arquivos arbitrários – inclusive arquivos somente-leitura de propriedade do root. Como o page cache é compartilhado entre processos, a alteração se torna visível instantaneamente para qualquer processo do sistema que leia o mesmo arquivo. Sobrescrever, por exemplo, parte do binário do sudo ou do passwd em cache abre caminho direto para root.

“O padrão DirtyClone repete a lição que Dirty Pipe ensinou em 2022 – sempre que páginas do page cache são compartilhadas entre subsistemas, qualquer caminho que escreva nessas páginas precisa preservar invariantes de propriedade, ou abre um canal direto entre código sem privilégios e dados privilegiados”, observa a análise da JFrog.

O CVSS 8.8 reflete a severidade prática: vetor local (precisa de execução de código sem privilégios na máquina-alvo), baixa complexidade de ataque, sem necessidade de interação do usuário, impacto crítico em confidencialidade, integridade e disponibilidade. Em ambientes multi-tenant – como contêineres, hosts compartilhados e Kubernetes – o impacto é direto: um pod hostil pode escapar para o host.

Quem é afetado

• Todas as distribuições Linux com kernels lançados antes do patch de 24 de maio de 2026 – inclui Debian, Ubuntu, RHEL/CentOS Stream, Rocky, Alma, SUSE, Arch e derivados
• Servidores multi-tenant: provedores de hospedagem compartilhada, plataformas SaaS, clusters Kubernetes onde pods executam código não confiável
• Ambientes de CI/CD com runners compartilhados executando builds de terceiros
• Desktops corporativos compartilhados ou estações com múltiplos usuários locais
• Dispositivos IoT, roteadores e gateways baseados em kernel Linux – geralmente os mais lentos a receber patches

Análise

DirtyClone é a terceira variante da mesma família de bugs de page cache divulgada em pouco mais de um mês – DirtyFrag, Fragnesia, e agora DirtyClone. Isso indica que a auditoria iniciada após o patch original encontrou caminhos adicionais para a mesma classe de problema. Historicamente, é comum que correções de uma falha como Dirty Pipe revelem novas instâncias ao longo dos meses seguintes, à medida que pesquisadores aplicam o mesmo modelo de exploração a outros subsistemas. Não há motivo para tratar DirtyClone como o último episódio dessa série.

O ponto crítico para defensores é que o PoC público encurta dramaticamente a janela entre divulgação e exploração em massa. A barreira para weaponizar a falha cai de “pesquisador especializado em kernel” para “qualquer atacante com acesso shell low-privilege”. Em datacenters compartilhados e plataformas cloud com tenants não confiáveis, isso é mudança imediata de postura – especialmente onde a aplicação de patches é lenta por SLAs de disponibilidade.

Para o Brasil, a leitura prática envolve dois grupos: provedores de hospedagem que ainda servem clientes em hosts compartilhados (muitos com kernels Long Term Support sem atualização recente) e ambientes Kubernetes corporativos onde a separação entre pods e host depende justamente da integridade do kernel. Vale auditar o backlog de patching antes que alguém apareça com a versão otimizada do PoC.

Recomendações práticas

• Aplique imediatamente o kernel atualizado fornecido pela sua distribuição – Debian, Ubuntu, RHEL e SUSE já liberaram pacotes desde o final de maio
• Em servidores que não podem reiniciar agora, considere livepatching (kpatch, kgraft, Ksplice) quando disponível em sua distro
• Audite quem tem shell local em hosts críticos – elimine contas locais não necessárias e fortaleça LDAP/SSH key inventory
• Em Kubernetes, atualize a versão do kernel dos nós e force restart dos nodes via drain ordenado; revise PodSecurityStandards para proibir pods privilegiados
• Para contêineres em multi-tenant: ative seccomp profiles restritivos e considere gVisor ou Kata Containers para isolar workloads não confiáveis em até a próxima janela de patch
• Monitore logs do kernel para mensagens suspeitas envolvendo skb, splice, copy_page e operações criptográficas em soquetes – artefatos potenciais de exploração
• Avalie a exposição do PoC público da JFrog em ambientes de teste antes de assumir que o problema está mitigado por configuração

Fonte: SecurityWeek