Vol. 2 | N. 5 | Pp. 147–149 | 2026 | ISSN xxxx-xxxx
Alerta: Vulnerabilidade DirtyDecrypt no Kernel Linux pode permitir escalar privilégio para root
DirtyDecrypt, também conhecida como DirtyCBC, é uma vulnerabilidade de escalação local de privilégios no kernel Linux que pode permitir que um atacante já com acesso local obtenha root em sistemas afetados. Não há um CVE oficial à essa vulnerabilidade. Recomenda-se atualização imediata de do kernel de máquinas Linux expostas. O problema parece estar no subsistema RxGK/RxRPC, especificamente em rxgk_decrypt_skb, por faltar uma proteção de copy-on-write (COW) [1].
O risco é elevado porque a exploração permite escalada de privilégios até root no host afetado. Em ambientes com containers, isso pode também viabilizar “escape de pod” [*] em nós vulneráveis, ampliando o impacto para o plano de execução subjacente. A disponibilidade de uma PoC pública reduz significativamente a complexidade de exploração e aumenta a probabilidade de uso oportunista por terceiros.
A cadeia de vulnerabilidades recentes nessa mesma superfície inclui Copy Fail, Dirty Frag e Fragnesia; todas exploram falhas de escrita na cache de páginas ou em subsistemas próximos para chegar a root. DirtyDecrypt entra nessa mesma linhagem, então vale tratá-la como um alerta sério para hardening e patch management em sistemas Linux modernos.
Não existe CVE
Não há um CVE oficial associado ao nome DirtyDecrypt nas reportagens, mas analistas apontam forte correspondência com CVE-2026-31635, corrigida no kernel principal em 25 de abril de 2026. Ou seja, o nome “DirtyDecrypt” parece ser a denominação dada pelos pesquisadores à mesma classe de falha ou a uma variante muito próxima. A falha CVE-2026-31635 [2] no kernel Linux, relacionada ao subsistema rxrpc/rxgk. A NVD descreve a correção como “rxrpc: fix oversized RESPONSE authenticator length check”
O que acontece
Em termos simples, a falha aceita “autenticadores de resposta” maiores do que deveria e isso pode acabar escrevendo dados na memória de processos privilegiados ou na cache de páginas de arquivos protegidos, inclusive binários SUID. Esse tipo de corrupção de memória abre caminho para execução com privilégios elevados.
Quem é afetado
A exploração exige um kernel Linux compilado com CONFIG_RXGK habilitado. Isso restringe o impacto principalmente a distribuições que seguem mais de perto o kernel upstream, como Fedora, Arch Linux e openSUSE Tumbleweed.
Correção permanente
A correção permanente é atualizar para um kernel que já inclua o patch; a mitigação temporária é bloquear os módulos esp4, esp6 e rxrpc quando não puder reiniciar imediatamente.
-
Verifique o kernel em uso com
uname -r. -
Atualize o sistema pelo gerenciador da sua distribuição.
-
Reinicie para subir no kernel corrigido.
-
Confirme após o reboot com
uname -rnovamente.
O ponto central é que o problema está no caminho rápido de descriptografia do kernel, então a correção real precisa vir do pacote de kernel atualizado; não basta alterar configuração de usuário comum.
Mitigação temporária
Se você não puder atualizar ou reiniciar agora, bloqueie o carregamento dos módulos vulneráveis com uma regra de modprobe e remova os módulos ativos em tempo de execução.
Use estes comandos como base:
sudo sh -c "printf 'install esp4 /bin/false\ninstall esp6 /bin/false\ninstall rxrpc /bin/false\n' > /etc/modprobe.d/dirtydecrypt.conf"sudo rmmod esp4 esp6 rxrpc 2>/dev/null || trueEssa medida impede que os módulos sejam carregados, mas pode quebrar funcionalidades que dependem deles, especialmente IPsec ESP e AFS/rxrpc.
Verificação prática
Depois de aplicar a mitigação, confirme se os módulos não estão carregados:
lsmod | egrep '^(esp4|esp6|rxrpc)'Exemplo por distribuição
Em sistemas da família Red Hat, AlmaLinux e derivados, o fluxo normalmente é: habilitar o repositório que contém o kernel corrigido, atualizar o pacote kernel*, reiniciar e validar a versão. Em ambientes que já receberam errata do fornecedor, basta atualizar o kernel pelo fluxo normal do sistema e rebootar.
Recomendações do analista
-
Aplicar o update de kernel no menor prazo possível.
-
Usar a blacklist dos módulos apenas como ponte temporária.
-
Validar se há uso real de
IPsec,AFSou dependência derxrpcantes de bloquear os módulos. -
Em servidores expostos, tratar a situação como prioritária porque já existe PoC pública.
Notas
[*] O “escape de pod” ocorre quando um processo comprometido dentro de um pod consegue sair do isolamento esperado e ganhar acesso ao nó hospedeiro ou a recursos fora do namespace do contêiner. Isso pode levar a leitura de arquivos do host, execução de comandos no nó e, em casos graves, escalada para privilégios de administrador local. Em termos práticos, o pod deixa de estar “preso” ao ambiente isolado e passa a interferir no sistema operacional subjacente.
Referências
[1] Bleeping Computer – Exploit available for new DirtyDecrypt Linux root escalation flaw
[2] NIST CVE-2026-31635 Detail – https://nvd.nist.gov/vuln/detail/CVE-2026-31635
Tags: Alerta, Cybersecurity, Linux, Linux Kernel, Vulnerabilidades.
Categorias: Kernel, Linux, root, Vulnerabilidade.