DirtyDecrypt PoC aumenta o risco de escalada de privilégios em kernels próximos ao mainline

Um teste de conceito público que aproveita uma vulnerabilidade recentemente corrigida no módulo rxgk do kernel Linux eleva o risco para sistemas que executam núcleos muito próximos à árvore principal: o exploit denominado DirtyDecrypt (ou DirtyCBC) Permite a um atacante com acesso local tornar-se root em determinadas configurações do sistema.

A raiz técnica do problema, segundo os pesquisadores que publicaram o PoC, é uma escrita em pagecache ocasionada pela falta de uma verificação de cópia-on-write (COW) na função rxgk_decrypt_skb: em termos simples, código do kernel acabou escrevendo onde não deveria sobre dados compartilhados, o que abre a porta a escalada de privilégios. A equipe V12 publicou o PoC e explica os detalhes em seu repositório ( V12 PoC: DirtyDecrypt), e a descrição encaixa com a correção registrada no NVD como CVE-2026-31635.

É importante salientar dois fatores que matizam o impacto: Primeiro, a exploração requer que o kernel esteja compilado com a opção CONFIG_RXGK habilitada (ou seja, suporte RxGK para AFS/rxrpc); portanto, só afeta distribuições que seguem de perto o kernel upstream — por exemplo Fedora, Arch ou openSUSE Tumbleweed— ou sistemas com kernels personalizados que incluam esse módulo. Segundo, o vetor é local: um atacante precisa executar código na máquina previamente (por exemplo, através de uma conta de usuário comprometida ou um processo malicioso com capacidades limitadas) para escalar o root.

A existência de um PoC público muda o limiar de risco: antes era uma falha corrigida em upstream, agora qualquer adversário com acesso local e conhecimentos básicos poderia reutilizar o teste para tomar controle total do sistema se o adesivo não estiver aplicado. Este padrão não é novo: nas últimas semanas apareceram falhas de escalada raiz da mesma família (Dirty Frag, Fragnesia, Copy Fail) e organismos como a CISA já avisaram e listam vulnerabilidades exploradas no catálogo conhecido ( CISA Known Exploited Vulnerabilities), o que evidencia uma onda de exploração ativa contra vetores de kernel.

O que devem fazer administradores e usuários: atualizar o kernel à versão que contém a correção o mais rapidamente possível; para ambientes de produção onde a atualização imediata não seja prática, aplicar mitigações temporárias e controlar o acesso local. Uma mitigação usada anteriormente contra falhas semelhantes consiste em evitar a carga dos módulos envolvidos criando uma regra em /etc/modprobe.d que impeça sua instalação, descarregando os módulos e esvaziando caches; tenha em conta que esta medida pode romper IPsec e sistemas de arquivos distribuídos AFS. Se a adotar, tente primeiro em ambientes controlados e compreenda o impacto sobre conectividade e serviços.

Para além de corrigir ou mitigar, verifique telemetria e integridade do sistema: procure sinais de escalada de privilégios ou persistência (sesões root inesperadas, binários SUID novos, processos anormais com UID 0, alterações em /etc, entradas suspeitas em dmesg ou syslog). Se você tiver detecção no kernel ou no EDR, verifique eventos relacionados com o rxgk ou operações de pagecache atípicas; se você não tiver essas ferramentas, considere implantar controles que limitem o acesso local e melhorar a segmentação de usuários e serviços.

Para equipamentos que gerem grandes frotas, valore aplicar backports de segurança oferecidos pela distribuição, usar serviços de livepatch onde estejam disponíveis e priorizar a atualização de kernels em bastiones ou máquinas com contas de múltiplos usuários. Mantenha um processo de resposta que inclua isolamento de hosts suspeitos, coleta de testes e restauração desde respaldos conhecidos limpos quando necessário.

A divulgação responsável e os testes públicos também nos lembram de uma lição operacional: as vulnerabilidades no espaço de kernel, embora locais, são muito valiosas para atacantes com acesso inicial e aceleram o movimento lateral e a persistência. Rever as opções de compilação do kernel em máquinas críticas (por exemplo, consultando a configuração do kernel ou os pacotes do fornecedor para ver se o CONFIG_RXGK está activo) ajuda a priorizar adesivos e mitigações com critério técnico.

Se quiser aprofundar os recursos técnicos e os avisos originais, consulte o PoC da equipe V12 no GitHub ( https://github.com/v12-security/pocs/tree/main/dirtydecrypt) e a entrada do NVD para a correção ( https://nvd.nist.gov/vuln/detail/CVE-2026-31635). Para políticas e seguimento de falhas exploradas no ecossistema, a base de CISA é uma referência útil ( https://www.cisa.gov/known-exploited-vulnerabilities-catalog).

Em resumo: adesivo já, reduzir o acesso local não essencial, monitorar indicadores de compromisso e preparar um plano de resposta. A disponibilidade pública de PoC obriga a assumir que, sem mitigação ou correção, a probabilidade de exploração aumentará rapidamente.