O DirtyClone e o bug do marcador Shared-Frag que não para de reaparecer

A versão resumida

Ir para a versão completa ↓

O que: DirtyClone, rastreado como CVE-2026-43503, é uma vulnerabilidade de escalonamento de privilégios locais no kernel do Linux, na pilha de rede: alguns caminhos de transferência de fragmentos skb descartam o SKBFL_SHARED_FRAG marcador que bloqueia gravações no próprio local, permitindo que os dados de entrada do ESP (IPsec) sejam descriptografados diretamente nas páginas do cache de páginas baseadas em arquivos. Trata-se de uma gravação arbitrária em arquivos somente leitura de propriedade do usuário root, um ataque Dirty COW por meio da pilha de rede, em vez de /proc/self/mem.

Impacto: Um usuário local sem privilégios transforma a perda do marcador em uma gravação no cache de página em um arquivo binário como /usr/bin/su, e então usa a imagem corrompida para obter privilégios de root. A JFrog publicou um passo a passo da exploração em 25 de junho; o PoC público (rafaeldtinoco/security/exploits/dirtyclone, baseado na primitiva DirtyFrag de Hyunwoo Kim) funciona em kernels mais antigos. O arquivo no disco nunca é alterado, por isso as ferramentas de integridade de arquivos não detectam a alteração.

Status: O DirtyClone pertence à família DirtyFrag/Fragnesia: um marcador de segurança se perde à medida que a memória respaldada por arquivo se move por caminhos de rede de alta velocidade, e uma gravação posterior no próprio local ocorre exatamente onde deveria ter sido copiada. A JFrog relatou a vulnerabilidade em 19 de maio; a correção foi lançada na versão v7.1-rc5 em 24 de maio. Isso faz com que se trate de um N-day para ambientes RHEL que não possuem parte da cadeia de correções, e não de um novo 0-day.

Gravidade: A Red Hat classifica como “Importante”, CVSS 7.0; o kernel.org atribui uma pontuação de 8,8, devido a uma classificação mais baixa de complexidade de ataque e a uma alteração no escopo (de “Inalterado” para “Alterado”), mas, de qualquer forma, o resultado é o acesso como root. Classe do bug: uma falha na propagação do marcador de fragmento compartilhado, causando gravações inseguras no local na memória respaldada pelo cache de páginas.

Por que isso é importante: Os sistemas expostos são aqueles em que o isolamento é o resultado: hosts multilocatários, executores de CI, nós de contêineres e do Kubernetes e ambientes de teste de desenvolvimento acessíveis por meio de CAP_NET_ADMIN, que muitas distribuições concedem por padrão a usuários sem privilégios dentro de um namespace. “Local” não significa “baixo risco” neste contexto.

Faça isso agora: A correção já está disponível nos feeds EL9 e EL10; portanto, atualize e reinicie o sistema. Se ainda não for possível aplicar o patch, desative os namespaces de usuários sem privilégios ou bloqueie esp4/esp6 carregamento automático quando o IPsec não estiver em uso. KernelCare Os usuários já dispõem de um patch que não requer reinicialização para os kernels EL9/EL10 afetados. Veja os detalhes a seguir.

Alguns dos bugs mais graves do kernel do Linux não surgem inicialmente como uma vulnerabilidade óbvia do tipo “gravação em arquivos raiz”. Eles começam como erros de registro. O DirtyClone é um desses casos. Um marcador de propriedade ausente em fragmentos do buffer de soquete é considerado confiável por uma operação de rede posterior, que então grava diretamente sobre ele.

A pilha de rede do Linux transporta pacotes de dados em buffers de soquete, ou skbs. Parte desses dados é mantida como fragmentos de página, em vez de ser copiada byte por byte para a memória privada. Isso é benéfico para o desempenho, mas não permite flexibilidade quanto à propriedade, pois um fragmento pode apontar para uma página compartilhada, de propriedade externa ou armazenada no cache de páginas. Antes que qualquer código grave nessa página, é necessário verificar se não há risco em alterá-la diretamente.

Essa é toda a função de SKBFL_SHARED_FRAG. O marcador indica ao código de processamento de pacotes posterior que um skb contém fragmentos compartilhados e que a modificação no local é proibida, a menos que o kernel primeiro copie os dados para a memória privada. O DirtyClone ocorre quando esse marcador se perde durante a transferência de fragmentos de um skb para outro. Nomes do NVD __pskb_copy_fclone() e skb_shift() entre os auxiliares que podem mover descritores de fragmentos sem transportar o marcador, deixando o SKB de destino com referências respaldadas pelo cache de páginas, enquanto skb_has_shared_frag() retorna falso.

Essa resposta incorreta é a vulnerabilidade. Um gravador in-place posterior verifica o skb, pergunta se os fragmentos são compartilhados, recebe uma resposta negativa e grava diretamente na página subjacente. Entrada do ESP em esp4.c é exatamente esse tipo de escritor, e é para lá que a exploração do público o leva.

O DirtyClone completa um conjunto desses bugs que surgiram ao longo da primavera, cada um com o mesmo modo de falha. A memória do cache de páginas baseada em arquivos é tratada como dados de pacotes comuns; em seguida, uma operação de rede no local grava onde deveria ter copiado. O Copy Fail surgiu primeiro, no final de abril. O DirtyFrag veio em seguida, em 7 de maio. O Fragnesia contornou o patch do DirtyFrag em 13 de maio. O DirtyClone é o quarto, alcançado por meio de mais um caminho de clonagem de pacotes que descarta o mesmo marcador de um bit.

Aqui está o ponto que deve orientar sua avaliação. O DirtyClone não é uma vulnerabilidade 0-day recém-descoberta que afeta infraestruturas totalmente atualizadas. O que a JFrog publicou em 25 de junho é uma demonstração de que caminhos de código residuais deixados abertos por uma correção parcial ainda são acessíveis. A palavra-chave é “completo”. Um kernel só está protegido quando contém toda a cadeia do DirtyFrag e do Fragnesia. Um kernel que recebeu a correção original do DirtyFrag, mas não as atualizações subsequentes, ainda possui um caminho acessível para o mesmo destino ESP. Os kernels EL9 e EL10 atuais da Red Hat já contêm o backport completo; é por isso que o perigo recai sobre os kernels que estão algumas atualizações atrasados, e não sobre os atuais.

Como funciona o DirtyClone

A cadeia pública vai desde uma configuração de socket sem privilégios até uma gravação arbitrária no cache de páginas com privilégios.

[Unprivileged user + network namespace]
│  attacker obtains CAP_NET_ADMIN inside the namespace
▼
[netfilter TEE rule clones ESP-in-UDP packets]
│  clone routed through __pskb_copy_fclone(), marker dropped
▼
[Mislabelled skb: references page-cache pages,
reports skb_has_shared_frag() == false]
▼
[XFRM ESP transport SA decrypts in place]
│  esp_input() AES-CBC writes over the target file's page cache
▼
[Arbitrary content in root-owned page cache]
│  overwrite /usr/bin/su (or /etc/sudoers.d/* via an NSS load)
▼
[uid=0 root shell]

O marcador. O kernel marca qualquer skb que contenha referências a páginas que não lhe pertençam com SKBFL_SHARED_FRAG, e skb_has_shared_frag() leia essa tag para decidir se uma carga útil pode ser modificada no próprio local. Quando um auxiliar de transferência de fragmentos move fragmentos paginados entre SKBs sem transportar o marcador, o SKB de destino mantém referências a páginas de propriedade externa ou respaldadas pelo cache de páginas, ao mesmo tempo em que informa que nada é compartilhado.

A pia. Um gravador posterior no mesmo local confia nesse relatório. No caso do DirtyClone, o gravador é esp_input() A descriptografia AES-CBC, que descriptografa diretamente essas páginas, incluindo o cache de páginas de arquivos de propriedade do usuário root e somente leitura. Com o controle da chave ESP e da associação de segurança, além das páginas de origem emendadas, o invasor transforma isso em uma gravação de conteúdo arbitrário no cache de páginas privilegiadas.

O trajeto. A Red Hat atribui a exposição do EL9 e do EL10 a skb_try_coalesce() perda do marcador (Bugzilla 2480902), e observa que a mesma perda pode ocorrer em toda uma família de auxiliares, incluindo __pskb_copy_fclone(), skb_shift(), skb_gro_receive(), e skb_segment(). A demonstração de conceito (PoC) pública acessa o mesmo destino ESP por uma porta diferente. Ela é executada dentro de um usuário sem privilégios e de um namespace de rede, instala uma regra TEE do netfilter que clona pacotes ESP-in-UDP por meio de __pskb_copy_fclone(), o que remove o marcador e, em seguida, instala SAs de transporte XFRM ESP para que o pacote clonado e com etiqueta incorreta seja descriptografado diretamente no cache de páginas do arquivo de destino.

O importante é que isso não é uma edição /usr/bin/su no disco, no sentido comum. Ele corrompe a cópia do cache de páginas na memória que o kernel posteriormente fornece a um caminho de execução privilegiado. É isso que torna o monitoramento convencional da integridade de arquivos um controle ineficaz nesse caso. O arquivo no disco permanece intacto; a modificação ocorre na cópia do kernel na memória; e uma reinicialização restaura o binário original, geralmente bem depois que o invasor já obteve privilégios de root.

Há um detalhe importante a ser considerado quanto ao escopo. O arquivo README do PoC indica uma janela restrita da versão principal v7.1-rc1 a rc4, mas testes internos reproduzem a vulnerabilidade sem modificações nos kernels retroportados para o EL9 e o EL10. Essa janela do upstream não delimita o impacto nas distribuições da família RHEL. Não interprete o intervalo de versões do README e conclua que sua máquina EL está fora do escopo.

O que a correção do Upstream altera

A correção é pequena, e é exatamente por isso que a família continua gerando variantes. Ela faz com que os auxiliares de transferência de fragmentos propaguem o marcador de fragmento compartilhado; assim, um skb de destino que ainda faça referência a páginas respaldadas pelo cache de páginas ou de propriedade externa relata skb_has_shared_frag() como verdadeiro. O gravador in-place posterior, então, se recusa a alterar essas páginas e recorre a uma cópia segura. A correção foi incorporada no código-fonte original em 21 de maio e lançada no Linux v7.1-rc5 em 24 de maio, como parte da mesma série que corrigiu os bugs anteriores relacionados ao DirtyFrag. Os IDs de commit da versão estável e do backport variam de acordo com o branch; portanto, consulte o comunicado da sua distribuição em vez de se basear em um único hash do código-fonte original.

Quem é afetado

Para usuários comuns do Linux, há risco caso o kernel em execução não possua a cadeia completa de correções para DirtyFrag, Fragnesia e DirtyClone e o sistema permita que código local não confiável tenha acesso aos recursos de rede necessários para a exploração. Relatórios públicos identificam o Debian, o Fedora e o Ubuntu entre as distribuições nas quais os namespaces de usuários sem privilégios tornam a exploração mais viável em configurações comuns. O Ubuntu 24.04 e versões posteriores adicionam restrições do AppArmor que podem bloquear a rota padrão da exploração, mas isso representa apenas um reforço de segurança em um caminho específico, não sendo prova de que o kernel subjacente tenha sido corrigido.

Para os sistemas da família RHEL, o panorama é mais restrito e se resume a duas questões: o kernel está sujeito às errata “DirtyFrag” e “Fragnesia”, e o host está executando um patch que não requer reinicialização?

Vulnerabilidade explorável, reproduzida internamente em kernels que não possuem a cadeia completa:

• EL9 ligado 5.14.0-611.49.2.el9_7, sobrescreve /usr/bin/su e rendimentos uid=0.
• EL10 ligado 6.12.0-55.27.1.el10_0, o mesmo resultado.

Não vulnerável:

• Kernels oficiais atuais que já incluem a correção completa para o DirtyFrag e o Fragnesia, como, por exemplo, o EL10 6.12.0-211.16.1.el10_2, onde o PoC não funciona.
• Qualquer servidor protegido pelo patch “rebootless” no esp4 módulo.

Não afetado pela vulnerabilidade CVE-2026-43503:

• RHEL 6, 7 e 8. A Red Hat indica que essas versões não são afetadas por esse CVE específico. Interprete isso com cautela. As listas de fluxos afetados variam entre os membros da família DirtyFrag; portanto, um fluxo que esteja isento do CVE-2026-43503 não está necessariamente isento de todos os CVEs relacionados.

A Red Hat lista o RHEL 9 e o RHEL 10, além do OpenShift RHCOS, como versões afetadas pela vulnerabilidade CVE-2026-43503. Isso indica a versão do código afetada, e não um host totalmente atualizado. Entenda “afetado” como “esse código foi fornecido nessas versões”, e não como “todas as máquinas RHEL 9 ou 10 atuais estão suscetíveis a exploração hoje”.

O prazo de atualização também varia de acordo com a distribuição e a versão do kernel. O CloudLinux (CL8 e CL9), em particular, pode apresentar atrasos em relação aos feeds do EL para essa família; portanto, os usuários do CL devem confirmar sua versão exata, em vez de presumir que há paridade.

Uma observação importante que se aplica a toda a família. Um host que simplesmente não atende às premissas do PoC não é o mesmo que um host que já foi corrigido. Confirme se o kernel contém todas as correções, em vez de presumir que uma tentativa malsucedida de exploração signifique que você está seguro.

Aja agora para mitigar

A solução definitiva é um kernel corrigido ou um patch que não exija reinicialização. Até que isso esteja disponível para todos, as medidas úteis são aquelas que eliminam os pré-requisitos da vulnerabilidade.

1. Instale a correção ou aplique primeiro uma correção que não exija reinicialização

Instale o kernel corrigido da sua distribuição e reinicie o sistema para usá-lo, ou aplique um patch que não exija reinicialização nos casos em que a reinicialização não for viável. A correção já está disponível nos repositórios do EL9 e do EL10; portanto, na maioria dos servidores, trata-se de uma atualização, e não de algo que exija espera.

2. Restringir os espaços de nomes de usuários sem privilégios

A rede precisa de CAP_NET_ADMIN de usuários sem privilégios para instalar a regra TEE e o SA do XFRM. Se isso for removido, o caminho público deixa de funcionar.

# EL family:
sudo sysctl -w user.max_user_namespaces=0
echo 'user.max_user_namespaces = 0' | sudo tee /etc/sysctl.d/99-dirtyclone.conf

# Debian / Ubuntu:
sudo sysctl -w kernel.unprivileged_userns_clone=0
echo 'kernel.unprivileged_userns_clone = 0' | sudo tee /etc/sysctl.d/99-dirtyclone.conf

Raio de impacto. Isso faz com que o Podman sem privilégios de root e o Docker sem privilégios de root deixem de funcionar, unshare(1), a sandbox do Chromium, algumas sandboxes de CI e os Flatpaks do bwrap. Aceitável na maioria das frotas de servidores com restrições de segurança, mas pode causar problemas em hosts de contêineres e de desenvolvedores. Teste antes de uma implantação em larga escala.

3. Impedir o carregamento automático do módulo ESP quando o IPsec não for utilizado

Não esp4 ou esp6, não há destino de descriptografia no próprio local para o caminho DirtyClone.

echo -e 'install esp4 /bin/false\ninstall esp6 /bin/false' | sudo tee /etc/modprobe.d/dirtyclone-esp.conf

Não aplique isso em hosts que utilizem IPsec ou XFRM, pois isso desativa o transporte ESP e interromperá seus túneis. Uma observação para toda a comunidade: o trabalho anterior sobre DirtyFrag também implicava rxrpc como um destino de gravação no local; portanto, a proteção contra toda a família pode significar o bloqueio rxrpc também. Essa configuração causa falhas no AFS e em outras cargas de trabalho que dependem do RxRPC; portanto, defina seu escopo com cuidado e aplique-a apenas onde esses recursos não estejam sendo utilizados. Para reverter qualquer medida de mitigação, remova os arquivos de substituição e recarregue o sistema.

sudo rm -f /etc/modprobe.d/dirtyclone-esp.conf /etc/sysctl.d/99-dirtyclone.conf
sudo sysctl --system

Momento decisivo. Se o servidor não executar IPsec nem contêineres sem privilégios de root, qualquer uma das opções funciona, e o bloqueio do módulo ESP representa a alteração menos invasiva. Se for necessário usar IPsec, mas não contêineres sem privilégios de root, desative os usuários sem privilégios. Se for necessário usar tanto IPsec quanto contêineres sem privilégios de root, um patch que não exija reinicialização ou um kernel corrigido é a única solução que não interrompe a carga de trabalho, e você deve isolar a execução local não confiável até que uma dessas soluções esteja em vigor.

Aplicação de patches sem reinicialização

É exatamente para esse tipo de bug que existem soluções de aplicação de patches sem reinicialização, como o KernelCare. Reinicializar uma frota para um kernel corrigido é fácil de dizer, mas difícil de programar, e a aplicação de patches sem interrupção resolve o mesmo problema sem afetar o tempo de atividade.

Nos kernels EL9 e EL10 afetados, isso ocorre no esp4 módulo e desativa o receptor de descriptografia de entrada do ESP exatamente no momento em que a gravação insegura ocorreria. Quando o marcador de fragmento compartilhado está ausente devido ao bug de propagação, a descriptografia no local sobre fragmentos respaldados pelo cache de páginas é recusada, em vez de ser executada. A mesma garantia da correção do marcador do upstream, só que implementada sem que ninguém precise recorrer a uma janela de manutenção.

Como o DirtyClone e o CVE-2026-46300 compartilham um mesmo bug de origem e uma mesma correção, um único patch que não requer reinicialização resolve ambos. É importante saber disso ao verificar a cobertura: em algumas ferramentas, a proteção aparece associada ao CVE-2026-46300, em vez de ao CVE-2026-43503, já que a atribuição do CVE pode demorar a ser atualizada em relação à correção em si.

O benefício aqui é limitado, mas real, e é exatamente nesse tipo de situação que a aplicação de patches sem reinicialização se destaca. Os hosts que correm maior risco são aqueles que estão atrasados nas atualizações do kernel, e esses são precisamente os hosts em que uma reinicialização de emergência é, desde o início, mais difícil de programar. Ser capaz de encerrar o DirtyClone nesses hosts sem essa reinicialização é a diferença entre corrigir o problema hoje e corrigi-lo na próxima janela de manutenção; e, para muitas frotas, é nesse intervalo que reside o risco real.

Detecção

Não há nenhuma assinatura confiável no disco para o DirtyClone, e isso constitui um elemento central do risco. A corrupção ocorre no cache de páginas; o binário no disco permanece intacto, e a evicção do cache ou uma reinicialização restauram os bytes originais. Isso não desfaz nenhuma persistência, alterações de conta ou atividades subsequentes após o invasor ter obtido privilégios de root. O hash de arquivos é um controle fraco nesse caso.

Pode ser que não deixe evidências evidentes de integridade dos arquivos, mas não é invisível. É mais provável que a detecção ocorra por meio de telemetria comportamental, e cada um dos itens a seguir constitui uma pista, e não uma prova:

• Inesperado esp4 ou esp6 o módulo é carregado em hosts que não executam o IPsec.
• Criação de um espaço de nomes de usuário sem privilégios, seguida logo em seguida pela instalação do XFRM SA ou pela inserção de uma regra do netfilter no TEE.
• Incomum nft, iptables, atividade XFRM ou TEE originada de contextos de usuário locais.
• Execução de um binário setuid, como, por exemplo, su ou sudo logo após essa configuração de rede, por um usuário que não tinha motivo para mexer em nenhum dos dois.
• A ausência repentina de eventos de auditoria de segurança esperados em um host que deveria estar gerando esses eventos.

Se algum código local não confiável ou parcialmente confiável tiver sido executado em um host EL9 ou EL10 exposto durante o período em questão, priorize a aplicação de patches e considere o host como merecedor de uma análise mais detalhada, em vez de interpretar a ausência de evidências no disco como ausência de comprometimento.

Por que este é importante

O DirtyClone não envolve execução remota de código e não significa que um usuário não autenticado da internet possa obter acesso root em qualquer servidor Linux. Para os ambientes em que essa falha realmente ocorre, essa distinção é um consolo insignificante. Os executores de CI executam o código de terceiros. Plataformas de hospedagem compartilhada executam o código dos clientes. Nós do Kubernetes executam contêineres com níveis de confiança variados. Sandboxes de desenvolvedores e hosts de compilação frequentemente permitem exatamente o comportamento de namespace que torna essa classe acessível. Em cada um desses casos, uma escalada de privilégios local é o evento que ultrapassa os limites. Isso transforma código que era executado onde era permitido em código que ganhou privilégios de root onde nunca deveria ter obtido.

A razão pela qual o DirtyClone apresenta menor urgência do que as manchetes sugerem é também a razão pela qual é fácil cometer erros. Um kernel que contenha a cadeia completa do DirtyFrag e do Fragnesia está protegido. Mas “completa” é a palavra-chave. Um kernel que recebeu o patch original do DirtyFrag e depois parou de receber atualizações ainda apresenta um caminho acessível, assim como qualquer host que esteja atrasado nas atualizações retroativas da distribuição. O risco se concentra nos sistemas que pularam a última janela de manutenção, nos executores de CI de longa duração que ninguém reinicia e nos servidores reservados para o próximo trimestre. Esses são exatamente os hosts em que um N-day como esse silenciosamente se torna um problema no mesmo dia. Um fluxo de trabalho baseado apenas em scanner que se concentra no fluxo de kernels afetados sem verificar a cadeia completa de correções pode tanto dar um falso alarme em hosts corrigidos quanto deixar passar aqueles que ainda estão expostos.

Lista de verificação de medidas corretivas priorizadas

1. Primeiro, aplique uma correção ou uma correção que não exija reinicialização nos sistemas EL9 e EL10 que estejam atrasados nas atualizações do kernel, especialmente hosts de contêineres, executores de CI, sistemas compartilhados e ambientes multilocatários.
2. Confirme se o kernel em execução possui a cadeia completa de correções para DirtyFrag, Fragnesia e DirtyClone, em vez de inferir a segurança com base no fracasso de uma tentativa de exploração.
3. Considere uma correção parcial do DirtyFrag como ainda vulnerável. Somente a cadeia completa elimina a vulnerabilidade.
4. Ao verificar a cobertura do “rebootless-patch”, é provável que a proteção apareça sob o CVE-2026-46300 em algumas ferramentas até que o mapeamento para o CVE-2026-43503 seja propagado.
5. O CloudLinux CL8 e o CL9 podem apresentar atrasos nas atualizações do EL para essa família; portanto, verifique qual é a sua versão exata.
6. Desative os espaços de nomes de usuários sem privilégios nos casos em que a carga de trabalho permitir.
7. Bloqueio esp4 e esp6 carregamento automático quando o IPsec não estiver em uso, e rxrpc o mesmo vale se você estiver se protegendo contra a família em geral e não usar o AFS ou o RxRPC.
8. Busca por namespaces incomuns, XFRM, ESP, TEE, nft, su, e sudo atividade durante o período de exposição e considerar os hashes de arquivos limpos como evidência insuficiente.

Aplique patches em qualquer kernel, sem necessidade de reinicialização. Se você ainda não é usuário do KernelCare, este é um bom momento para descobrir como a aplicação de patches sem reinicialização protege sistemas Linux críticos, sem a necessidade de janelas de manutenção de emergência ou tempo de inatividade.

Adquira o KernelCare hoje mesmo →

Referências

• Red Hat CVE-2026-43503, Importante, CVSS 7.0, RHEL 9 e 10 afetados, RHEL 6/7/8 não afetados; Bugzilla 2480902
• Dados de segurança da Red Hat em JSON, CVE-2026-43503
• NVD CVE-2026-43503 (pontuação CNA do kernel.org: 8,8, alteração no escopo)
• Rastreador de Segurança do Debian, CVE-2026-43503
• Relacionado ao CVE-2026-46300 (Bugzilla 2477015), mesma falha de origem por meio de skb_try_coalesce, compartilha a solução
• Pesquisa de Segurança da JFrog, “Análise e exploração de uma variante do LPE no Linux: DirtyClone (CVE-2026-43503)”
• SecurityWeek: Vulnerabilidade “DirtyClone” no kernel do Linux leva ao acesso como root
• The Hacker News: Nova falha no kernel do Linux, chamada “DirtyClone”, permite que usuários locais obtenham privilégios de root por meio de pacotes clonados
• PoC público, rafaeldtinoco/security/exploits/dirtyclone (JFrog; primitiva DirtyFrag ESP de Hyunwoo Kim)
• Correção no código principal do Linux v7.1-rc5