Poucos dias depois da divulgação do Copy Fail, o ecossistema Linux voltou a entrar em estado de alerta. Desta vez, o problema atende pelo nome de Dirty Frag, uma nova falha de escalonamento local de privilégios que atinge diretamente o kernel Linux e reacende uma discussão que vem crescendo nos bastidores da comunidade há anos: o ciclo entre a divulgação pública de vulnerabilidades e a distribuição efetiva de correções está começando a ficar rápido demais para a própria infraestrutura do ecossistema acompanhar.
A vulnerabilidade foi divulgada publicamente pelo pesquisador Hyunwoo Kim e, embora não permita execução remota de código, o impacto potencial é considerado severo. Em sistemas vulneráveis, um usuário local sem privilégios, ou mesmo um container comprometido, pode obter acesso root explorando caminhos específicos do kernel relacionados ao processamento de páginas de memória.
O problema afeta diretamente ambientes multiusuário, hosts de containers, runners de CI/CD, clusters Kubernetes e infraestruturas compartilhadas em geral. Em outras palavras: exatamente o tipo de ambiente que hoje sustenta boa parte da internet moderna. E existe um agravante importante aqui: exploits públicos já circulam livremente.
Dirty Frag não é o novo Dirty Pipe, mas pertence à mesma família
O nome inevitavelmente remete ao Dirty Pipe, vulnerabilidade que abalou o Linux em 2022 ao permitir sobrescrever arquivos protegidos através do page cache do kernel. O Dirty Frag segue uma lógica parecida, embora explore caminhos diferentes.
Segundo os detalhes divulgados por Hyunwoo Kim, o ataque combina dois problemas distintos:
- CVE-2026-43284, relacionado ao subsistema IPsec ESP/XFRM
- CVE-2026-43500, ligado ao RxRPC
Ambos exploram uma classe de bugs envolvendo a corrupção do page cache do kernel durante operações com buffers paginados.
Dessa maneira, o kernel acaba manipulando páginas de memória que ainda possuem referências acessíveis a processos sem privilégios. Isso abre espaço para a corrupção de dados sensíveis e, eventualmente, o escalonamento de privilégios até o root.
Embora o impacto lembre o Copy Fail divulgado recentemente, os dois problemas são tecnicamente diferentes. O Copy Fail explorava o subsistema criptográfico do kernel através do algif_aead. Já o Dirty Frag mira caminhos ligados ao ESP/XFRM e ao RxRPC, componentes associados principalmente a IPsec e AFS.
Ainda assim, ambos pertencem a uma tendência preocupante: falhas modernas no kernel Linux estão se concentrando cada vez mais em caminhos internos altamente complexos ligados à manipulação de memória, page cache, networking e aceleração de operações em kernel space.
E esse tipo de vulnerabilidade costuma ser especialmente perigoso porque não depende de condições improváveis nem de cenários extremamente específicos. Segundo a própria Red Hat, o Dirty Frag é uma falha lógica determinística, de modo que, quando as condições certas existem, a exploração tende a funcionar de forma confiável.
O problema não é só o bug
O aspecto talvez mais preocupante do Dirty Frag não seja apenas a vulnerabilidade em si, mas o contexto em que ela apareceu. Segundo relatos publicados por distribuições e mantenedores, o embargo de divulgação responsável foi rompido antes que patches amplamente distribuídos estivessem prontos.
O resultado foi um cenário complicado: um exploit público disponível enquanto boa parte das distribuições ainda avaliava o impacto, adaptava as correções ou iniciava processos internos de validação.
A AlmaLinux, por exemplo, decidiu liberar kernels corrigidos antes mesmo de atualizações equivalentes chegarem oficialmente ao ecossistema Red Hat Enterprise Linux.
Em comunicado público, o projeto afirmou que a gravidade da falha e a existência de exploits públicos tornavam inviável esperar pelo ciclo tradicional de upstream. Os kernels corrigidos chegaram primeiro aos repositórios de testes e depois foram promovidos rapidamente para produção.
O Debian ainda mantém várias versões vulneráveis, incluindo Bookworm e Trixie, enquanto a correção aparece apenas parcialmente integrada ao Debian Sid.
O Ubuntu confirmou o impacto em praticamente todas as versões suportadas atualmente, incluindo 20.04 LTS, 22.04 LTS, 24.04 LTS e até a 26.04 LTS. A Canonical também chamou atenção para um ponto particularmente sensível: em ambientes com containers arbitrários, o Dirty Frag pode potencialmente facilitar cenários de fuga de container, embora não exista nenhuma prova de conceito pública a respeito.
A Red Hat também confirmou impacto no RHEL 8, 9 e 10, além do OpenShift 4. E é justamente no OpenShift que a situação mostra o tamanho real do problema.
Quando a mitigação vira um mini projeto de infraestrutura
Em teoria, a recomendação é simples: atualizar o kernel e reiniciar a máquina. Na prática, isso raramente é trivial em grandes ambientes corporativos.
Clusters Kubernetes, hosts de containers, plataformas OpenShift e ambientes de CI/CD normalmente operam com janelas de manutenção limitadas, workloads distribuídos e requisitos rígidos de disponibilidade.
Por isso, enquanto patches definitivos não chegam, distribuições e fornecedores começaram a recomendar mitigações temporárias por meio do bloqueio de módulos vulneráveis do kernel.
Os principais alvos são:
- esp4
- esp6
- rxrpc
Algumas orientações também incluem módulos relacionados ao IPsec compression, como ipcomp4 e ipcomp6.
O problema é que essa mitigação não é neutra. Desabilitar esses módulos pode quebrar VPNs IPsec, ambientes que utilizam StrongSwan, LibreSwan, implementações de AFS e outras cargas específicas de rede. No caso do OpenShift, a própria Red Hat publicou um procedimento relativamente complexo envolvendo DaemonSets privilegiados para aplicar blacklist automática dos módulos em todos os nós do cluster.
O que deveria ser uma “mitigação temporária” acaba exigindo coordenação operacional, validação de workloads e análise cuidadosa de impacto.E isso ajuda a explicar por que falhas locais de escalonamento de privilégios continuam sendo extremamente relevantes mesmo sem execução remota de código.
Hoje, em ambientes modernos, workloads não confiáveis já executam código constantemente dentro da infraestrutura. CI runners recebem código externo o tempo inteiro. Containers compartilham o mesmo kernel do host. Plataformas multiusuário vivem em isolamento parcial. Nesse cenário, uma falha local pode rapidamente virar um problema sistêmico.
Um “killswitch” emergencial
O impacto combinado de Copy Fail e Dirty Frag acabou produzindo uma reação incomum entre desenvolvedores do kernel Linux. Sasha Levin, engenheiro da NVIDIA e co-maintainer do Linux stable, propôs um mecanismo de emergência que vem sendo apelidado informalmente de “killswitch” do kernel.
A ideia é relativamente simples: permitir que administradores desativem dinamicamente funções específicas do kernel consideradas vulneráveis até que um patch definitivo esteja disponível. Em vez de executar normalmente, a função retornaria erro imediatamente.
O mecanismo não corrige a vulnerabilidade, não substitui live patching e tampouco resolve o problema estrutural. Mas poderia reduzir drasticamente a superfície de ataque durante o intervalo entre a divulgação pública e a distribuição efetiva das correções.
Segundo Levin, o foco seriam caminhos pouco utilizados na maioria dos sistemas, incluindo:
- AF_ALG
- ksmbd
- nf_tables
- vsock
- ax25
O próprio Copy Fail aparece como caso de teste dentro do patch proposto. A ideia, porém, divide opiniões. Por um lado, administradores ganhariam uma ferramenta rápida para reagir a falhas críticas sem esperar ciclos completos de atualização.
Por outro, desligar funções arbitrárias do kernel em runtime pode gerar efeitos colaterais imprevisíveis. O próprio Levin reconhece isso na proposta: não existe validação automática para garantir que determinada função pode ser desativada com segurança.
Ainda assim, o simples fato de uma proposta dessas estar sendo discutida já revela uma mudança importante no clima dentro da comunidade kernel.
Historicamente, o Linux sempre privilegiou correções definitivas em vez de mecanismos paliativos. Mas a combinação entre divulgação pública acelerada, exploits circulando rapidamente e cadeias modernas de distribuição está começando a pressionar esse modelo.
O Linux continua seguro, mas o cenário ficou mais agressivo
É importante separar as coisas. O Dirty Frag não significa que o Linux virou um sistema inseguro da noite para o dia, mas a vulnerabilidade expõe algumas tendências importantes. A primeira é que o kernel Linux moderno se tornou gigantesco, extremamente complexo e profundamente integrado a workloads de nuvem, containers, virtualização e networking avançado. Isso inevitavelmente amplia superfície de ataque.
A segunda é que o intervalo entre descoberta, divulgação pública e exploração prática está cada vez menor. E a terceira talvez seja a mais importante: vulnerabilidades locais deixaram de ser problemas “menores” num mundo dominado por containers, CI/CD e infraestrutura compartilhada.
Em 2026, acesso local já não significa necessariamente acesso físico à máquina. Muitas vezes significa apenas conseguir executar código dentro de algum workload parcialmente isolado.
Ajude o Diolinux a seguir crescente e independente: seja membro Diolinux Play e receba benefícios exclusivos!