Dirty Frag: a vulnerabilidade determinista do Linux que permite obter root com um único comando

Surgiram detalhes de uma nova vulnerabilidade local de escalada de privilégios no kernel do Linux apodada Dirty Frag, que combina duas falhas de escrita na cache de páginas para obter privilégios root sem necessidade de condições de carreira. De acordo com a pesquisa publicada por Hyunwoo Kim, a exploração encadeia uma vulnerabilidade no subsistema IPSec (xfrm-ESP Page‐Cache Write) com outra em RxRPC (RxRPC Page‐Cache Write), e sua natureza é determinista, sem depender de janelas de tempo, o que eleva significativamente a taxa de sucesso e a seriedade do risco para sistemas sem adesivo.

O problema é especialmente relevante porque toca caminhos de recepção em que o kernel decifra diretamente sobre páginas que estão realmente referenciadas por processos de usuário (por exemplo, páginas de pipe anexadas por splice/sendfile ou MSG_SPLICE_PAGES), o que pode expor ou corromper texto plano que um processo não privilegiado ainda mantém. A combinação abrange cenários complementares: em distribuições que permitem a criação de namespaces de usuário o ataque IPSec pode ser executado, enquanto no Ubuntu - onde a criação de namespaces está bloqueada pela AppArmor - o módulo rxrpc, carregado por defeito, torna possível a outra variante. Isso significa que muitas distribuições populares estão expostas(mencionadas entre elas Ubuntu 24.04.4, RHEL 10.1, Fedora 44, CentOS Stream 10, AlmaLinux 10 e openSUSE Tumbleweed), e também existe um teste de conceito funcional que permite obter root com um único comando, o que aumenta a urgência.

Do ponto de vista histórico, os vetores envolvidos lembram falhas anteriores da família Dirty Pipe e Copy Fail, mas Dirty Frag não depende do módulo algif_ aead nem de suas mitigações conhecidas, pelo que sistemas previamente "parcheados" contra Copy Fail podem continuar sendo vulneráveis. Além disso, as raízes do problema remontam a commits do kernel de 2017 e 2023, o que sublinha como mudanças antigas podem ativar cadeias novas e perigosas anos depois.

Enquanto os mantenedores do kernel trabalham em adesivos, as medidas de mitigação temporárias são críticas para reduzir a superfície de ataque em servidores e estações de trabalho expostos a usuários locais ou a ambientes multiutilizados. Entre as ações mais efetivas e de baixo risco está evitar que os módulos afectados sejam carregados(esp4, esp6 e rxrpc) até chegar a um adesivo oficial; isto pode ser alcançado criando regras em /etc/modprobe.d/ que impeçam a carga automática do módulo ou que redirecionem a sua instalação para /bin/false, e verificando a ausência de lsmod. Outra mitigação complementar é desativar a clonagem de namespaces por usuários não privilegiados (sysctl kernel.unprivileged_userns_clone=0), e em ambientes Ubuntu verificar a política de AppArmor porque em muitos casos impede o primeiro vetor (xfrm) ao bloquear a criação de user namespaces. Para mais detalhes sobre como e onde gerenciar a carga de módulos consulte a documentação oficial do kernel em Kernel.org — administração de módulos e documentação do AppArmor que mantém a Canonical em Ubuntu — AppArmor.

É importante planejar essas mitigações com critério operacional: bloquear módulos ligados ao IPSec ou RxRPC pode ter impacto funcional em serviços que dependem do IPSec/ESP ou do núcleo de RxRPC, pelo que deve ser avaliado o efeito em aplicações e conectividade antes de aplicar mudanças em produção. Além disso, mantenha controlos de acesso a contas locais, restrinja a possibilidade de subir e executar binários por usuários não confiáveis, audite mudanças em arquivos SUID/SGID e monitorize sinais de exploração (creação de shells com privilégios, cargas incomuns de módulos, atividade de processos desconhecidos).

Finalmente, quando os adesivos oficiais estiverem disponíveis, aplique-os com prioridade e verifique que o kernel actualizado efetivamente corrige as referências envolvidas. A longo prazo, este incidente torna claro a necessidade de minimizar o attack sulface em hosts expostos: Desactivar módulos desnecessários, aplicar princípios de menor privilégio para usuários locais e manter imagens base o mais simples possível reduz a probabilidade de cadeias como o Dirty Frag serem exploradas em seu ambiente. Para seguir o estado de vulnerabilidades e atualizações confie em fontes centralizadas como o NVD e a árvore oficial do kernel: NVD — National Vulnerability Database e Kernel.org.