Publicado proof-of-concept para a vulnerabilidade DirtyDecrypt, também conhecido como DirtyCBC, permitindo que um usuário local não privilegiado obtenha direitos de root em alguns sistemas Linux. O problema está no código rxgk do subsistema RxRPC e está relacionado à gravação no cache de páginas devido à verificação ausente de copy-on-write na função rxgk_decrypt_skb(). A publicação do PoC em 18 de maio de 2026 foi reportada pela BleepingComputer; o próprio PoC está hospedado no repositório da equipe V12.
RxRPC é um protocolo de rede do kernel Linux sobre UDP, fornecendo transporte confiável para operações remotas. A documentação do kernel menciona separadamente que AFS — Andrew File System — é um exemplo de aplicação que utiliza RxRPC, e o próprio protocolo suporta negociações de segurança da conexão. Esta área é relacionada ao RxGK, utilizado para o modo seguro do RxRPC/AFS.
De acordo com a descrição da V12, o DirtyDecrypt é mais uma variação das vulnerabilidades da classe CopyFail / Dirty Frag / Fragnesia. Todas elas giram em torno de uma ideia semelhante: o manuseio inadequado da memória do kernel, do cache de páginas e dos buffers pode permitir que um processo local não privilegiado afete dados que deveriam estar indisponíveis para gravação. No caso do DirtyDecrypt, trata-se da 'gravação no cache da página rxgk' devido à proteção COW ausente em rxgk_decrypt_skb().
A equipe V12 afirma que descobriu e reportou o problema 9 de maio de 2026, mas os mantenedores do kernel responderam que isso é um duplicado de um erro já corrigido. Depois disso, os pesquisadores publicaram o PoC, argumentando que a correção já está no kernel principal.
A situação com o CVE não parece ser muito clara. A BleepingComputer escreve que não há um CVE oficial separado para o nome DirtyDecrypt no momento da publicação, mas o analista Will Dormann associa os detalhes publicados pela V12 com CVE-2026-31635, corrigido no final de abril. Na base NVD, a CVE-2026-31635 é descrita como um erro no rxrpc: a função rxgk_verify_response() verificava incorretamente o comprimento do autenticador de resposta, de modo que um autenticador muito grande poderia chegar a rxgk_decrypt_skb() e levar o código a BUG_ON(len).
Ou seja, publicações públicas ligam o DirtyDecrypt a CVE-2026-31635, mas a descrição formal da CVE na NVD ainda parece ser mais restritiva e fala principalmente sobre o erro de verificação de comprimento no rxrpc, e não diretamente sobre o alias DirtyDecrypt/DirtyCBC como um registro separado. Portanto, é mais correto dizer: DirtyDecrypt provavelmente corresponde ou está intimamente relacionado ao CVE-2026-31635, e não afirmar que este é o nome oficial do CVE.
Para operação, é necessário um núcleo com a opção habilitada CONFIG_RXGK, que inclui suporte a RxGK para o cliente AFS e transporte de rede. Isso restringe consideravelmente o número de sistemas afetados: antes de tudo, trata-se de distribuições que acompanham rapidamente o núcleo upstream, incluindo Fedora, EPEL para RHEL/CentOS e openSUSE Tumbleweed. A BleepingComputer enfatiza que o PoC V12 publicado foi testado apenas no Fedora e no núcleo mainline.
O DirtyDecrypt surgiu em meio a uma série de vulnerabilidades semelhantes de LPE no Linux. Anteriormente foram reveladas Falha de Cópia em algif_aead, Dirty Frag nos componentes de rede, e depois Fragnesia no XFRM ESP-in-TCP. A Microsoft descreveu o Dirty Frag como uma elevação de privilégios local através dos componentes esp4, esp6 e rxrpc, permitindo que um invasor, após obter acesso local, se eleve a root e se mantenha no sistema.
O perigo prático de tais falhas é que elas são frequentemente exploradas após uma invasão inicial: por exemplo, após a compromissão de uma conta SSH, uma shell web, um contêiner vulnerável ou um usuário de serviço de baixo privilégio. Ao obter root, o invasor pode desativar medidas de segurança, ler segredos, alterar logs, implantar persistência e avançar pela infraestrutura.
Os usuários de distribuições rolling-release potencialmente afetadas devem instalar as últimas atualizações do núcleo. Para sistemas onde a atualização imediata não é possível, publicações mencionam medidas temporárias, como desativar módulos rxrpc não utilizados e componentes relacionados, no entanto, tais soluções alternativas podem quebrar o AFS e parte dos cenários IPsec/VPN, portanto, devem ser aplicadas apenas após a verificação do impacto no sistema específico.
Para a maioria das instalações de desktop e servidor, o risco é provavelmente menor do que o do Copy Fail: o DirtyDecrypt requer uma configuração específica do núcleo e a execução local de código. No entanto, para Fedora, Arch Linux, openSUSE Tumbleweed e outros sistemas com atualizações rápidas do núcleo, o problema merece atenção: já não é um relatório teórico, mas uma vulnerabilidade com PoC publicado e um caminho claro para elevação de privilégios.
Fonte: linux.org.ru
