CVE-2026-31635 permite escrita indevida em page cache no caminho rxgk_decrypt_skb() quando kernels vulneráveis usam CONFIG_RXGK, com risco de escalonamento local para root.
| Componente | Kernel Linux no caminho rxgk_decrypt_skb() do subsistema rxgk, com exposição condicionada a builds com CONFIG_RXGK habilitado. |
| Vetor | Um usuário local não privilegiado aciona o processamento de sk_buff recebido em um fluxo vulnerável; a ausência de guarda copy-on-write permite escrita em páginas compartilhadas. |
| Impacto | Modificação de page cache ou memória associada a objetos privilegiados, com possibilidade de escalonamento local para root; em nós de containers, a falha pode apoiar fuga de pod porque o host kernel é compartilhado. |
| Prioridade | Atualizar o kernel para uma versão corrigida da distribuição, confirmar a presença de CONFIG_RXGK, reiniciar os hosts após patch e investigar alterações anômalas em arquivos privilegiados. |
| Versões | As versões exatas dependem do pacote e dos backports de cada distribuição; a exposição citada envolve distribuições com CONFIG_RXGK habilitado, incluindo Fedora, Arch Linux e openSUSE Tumbleweed. |
| Artefatos | PoC público chamado DirtyDecrypt, também referenciado como DirtyCBC; identificador CVE-2026-31635; função afetada rxgk_decrypt_skb(); pontuação CVSS informada como 7.5. |
| Mitigação | Aplicar correção de kernel, remover ou evitar kernels com o caminho vulnerável quando o recurso não for necessário, reduzir execução de código não confiável em hosts afetados e validar integridade de /etc/shadow, /etc/sudoers e binários SUID. |
DirtyDecrypt é uma prova de conceito pública para CVE-2026-31635, uma vulnerabilidade de escalonamento local de privilégios no kernel Linux. O defeito está no caminho rxgk_decrypt_skb(), função usada para descriptografar um sk_buff recebido no lado de recepção do subsistema rxgk. O problema técnico central é a falta de uma proteção de copy-on-write antes de uma escrita em página que pode estar compartilhada com page cache ou com outro contexto de processo. Em um kernel correto, a escrita em uma página compartilhada precisa provocar uma cópia privada antes da modificação; sem essa barreira, a alteração pode atingir dados que deveriam permanecer isolados. Ação defensiva imediata é tratar hosts com kernel vulnerável e CONFIG_RXGK como ativos de alta prioridade para correção e reinicialização controlada.
A falha foi relatada em 9 de maio de 2026 e acabou relacionada a uma correção já presente na árvore principal do kernel, o que transforma a publicação do PoC em um risco típico de n-day: o defeito tem patch conhecido em algum fluxo, mas nem todos os ambientes necessariamente receberam pacote corrigido, reboot e validação. O impacto não é remoto por padrão; ele depende de execução local. Ainda assim, o efeito operacional é severo em servidores multiusuário, estáções de engenharia, runners de CI/CD, hosts de virtualização leve e nós Kubernetes, porque código executado com baixa confiança pode tentar converter uma primitiva de escrita em page cache em alteração de arquivos como /etc/shadow, /etc/sudoers ou binários SUID. A resposta deve combinar patch, redução de exposição local e revisão de integridade.
O fluxo vulnerável começa quando o kernel processa um buffer de socket recebido e entra em rxgk_decrypt_skb(). Nesse caminho, páginas de memória podem estar parcialmente compartilhadas com o page cache, uma otimização comum em Linux para evitar cópias desnecessárias. A garantia de segurança esperada é que qualquer escrita sobre página compartilhada passe por uma verificação de copy-on-write; se a página pertence logicamente a outro consumidor, o kernel deve criar uma cópia privada antes de alterar bytes. Em DirtyDecrypt, a ausência dessa guarda transforma uma operação de descriptografia ou manipulação do buffer em uma escrita que atravessa o limite lógico da página. O resultado é uma primitiva de corrupção direcionável: o atacante local tenta fazer com que a escrita caia sobre conteúdo privilegiado mapeado ou cacheado e, a partir disso, altera estado que não deveria ser modificável por sua conta.
O caminho de exploração depende de precondições locais: o sistema precisa executar um kernel afetado, o recurso rxgk precisa estar habilitado por configuração, e o atacante precisa conseguir acionar a sequência que leva ao sk_buff processado pela função vulnerável. A notícia técnica não fornece hashes, payloads ou comandos do PoC, portanto qualquer detecção baseada em assinatura de arquivo seria fraca sem telemetria adicional. A classe da falha, porém, é consistente com outros bugs recentes de page-cache write, como CVE-2026-31431, CVE-2026-43284, CVE-2026-43500 e CVE-2026-46300, nos quais a falha de isolamento entre página compartilhada, pipe, socket ou subsistema de transporte vira uma escrita em conteúdo aparentemente somente leitura. O impacto real surge quando essa escrita altera material sensível o suficiente para obter root, como credenciais locais, regras de sudo ou metadados executáveis.
A superfície afetada não é todo kernel Linux de forma indistinta. A exposição conhecida está condicionada a builds com CONFIG_RXGK habilitado, incluindo distribuições citadas como Fedora, Arch Linux e openSUSE Tumbleweed. Ambientes com kernels customizados, imagens de appliance, hosts de laboratório e nós de computação que acompanham a árvore principal mais de perto devem ser avaliados pela configuração efetiva, não apenas pelo nome da distribuição. Em containers, o ponto crítico é que a falha ocorre no host kernel; se uma carga dentro de pod conseguir satisfazer as precondições do caminho vulnerável, a exploração local pode deixar de ser apenas comprometimento do container e virar risco ao nó. Essa condição exige revisão de quais clusters executam workloads de terceiros, pipelines não confiáveis ou jobs com acesso de shell.
- Hosts Linux com
CONFIG_RXGK=you recurso equivalente habilitado no kernel distribuído pelo fornecedor. - Servidores multiusuário, runners de CI/CD e estáções onde usuários sem privilégio conseguem compilar ou executar código arbitrário.
- Nós Kubernetes ou ambientes containerizados que compartilham o host kernel com pods de baixa confiança.
- Arquivos privilegiados usados como alvo de alteração de page cache, incluindo
/etc/shadow,/etc/sudoerse binários SUID.
A caça deve começar por inventário de kernel e configuração, porque a presença do PoC público aumenta a chance de tentativa em hosts ainda não corrigidos. Colete versão do kernel em execução, pacote instalado, tempo desde o último reboot e configuração efetiva relacionada a CONFIG_RXGK. Depois correlacione com sinais de escalonamento local: criação súbita de shells root, alteração de grupos, modificação de contas, surgimento de binários SUID fora de janelas de manutenção e mudanças de integridade em arquivos protegidos sem evento userland compatível. Bugs de page cache podem não gerar o mesmo rastro que uma escrita normal feita por editor ou gerenciador de pacotes, então divergências entre auditd, EDR, FIM e hashes de baseline são mais importantes do que procurar apenas um processo abrindo /etc/shadow para escrita.
Em ambientes de containers, a telemetria deve incluir eventos do nó, não só do pod. Procure pods que executaram compiladores, ferramentas de exploração, chamadas de baixo nível incomuns, binários recém-criados em diretórios temporários e processos que mudaram de UID ou namespace de forma inesperada. Em CI/CD, revise jobs executados no período entre a divulgação e a aplicação do patch, especialmente pipelines que rodam código de pull requests, artefatos de terceiros ou testes com permissões amplas. Não há IoCs de rede confirmados para DirtyDecrypt no material disponível; o foco defensivo deve ser comportamento local, integridade de arquivos e confirmação de correção.
- Kernel vulnerável em execução após pacote corrigido instalado, indicando ausência de reboot efetivo.
- Alterações de hash,
ctimeou permissões em/etc/shadow,/etc/sudoersou binários SUID sem mudança correspondente em tickets ou janelas de manutenção. - Processos locais de baixa confiança criando binários executáveis em
/tmp, diretórios de workspace, caches de build ou volumes de pod. - Eventos de
sudo, login local ou criação de usuário logo após execução de código não confiável no mesmo host. - Divergência entre baseline de integridade e logs de escrita userland, sinal compatível com alteração mediada por primitiva de kernel.
A mitigação principal é aplicar o kernel corrigido da distribuição e reiniciar o sistema para garantir que o kernel em execução deixou de ser vulnerável. Em parques grandes, priorize hosts onde usuários sem privilégio, workloads de terceiros, jobs de CI/CD ou pods não confiáveis executam código. A simples instalação do pacote não encerra o risco enquanto o kernel antigo permanecer carregado. Depois do reboot, confirme versão em execução, configuração efetiva e ausência de processos herdados de janelas anteriores. Para sistemas em que rxgk não é necessário e a distribuição oferecer kernel alternativo ou configuração sem o recurso, remover a superfície reduz a dependência de resposta emergencial em futuras variantes de page-cache write.
A contenção deve considerar que uma exploração bem-sucedida altera confiança do host. Se houver indício de tentativa ou comprometimento, isole a máquina, preserve memória e disco conforme política de DFIR, exporte logs de auditd, EDR, shell history, CI/CD e orquestrador, e valide arquivos privilegiados contra baseline confiável. Rotacione segredos locais expostos no host se a investigação indicar privilégio root obtido ou acesso a material sensível. Para Rocky Linux e outras distribuições que ofereçam canais opcionais de segurança acelerada, avalie o trade-off operacional: repositórios emergenciais podem entregar correções antes do fluxo regular, mas exigem controle de versão, teste de compatibilidade e acompanhamento para não perder a correção quando o pacote upstream posterior substituir o kernel instalado.
- Aplicar atualização de kernel da distribuição e executar reboot planejado, validando a versão carregada com telemetria de inventário.
- Mapear hosts com
CONFIG_RXGKe suspender temporariamente execução de código não confiável nesses sistemas até a correção estar ativa. - Executar verificação de integridade em
/etc/shadow,/etc/sudoers, binários SUID, contas locais, chaves SSH e permissões críticas. - Revisar runners e nós Kubernetes expostos a workloads externos, movendo cargas sensíveis para hosts já corrigidos.
- Quando houver suspeita de exploração, tratar o host como comprometido, preservar evidências e reconstruir a partir de imagem confiável se a integridade não puder ser demonstrada.
0 Comentários