Dirty Frag (CVE-2026-43284): o bug do kernel Linux que transforma acesso de leitura em root

Um ficheiro de leitura exclusiva deve permanecer de leitura exclusiva. O Dirty Frag (CVE-2026-43284, CVE-2026-43500 e CVE-2026-46300) faz com que o kernel Linux edite a respetiva cópia em cache de qualquer forma.

Este bug permite que um programa executado quase sem privilégios escreva em ficheiros aos quais apenas deveria ter acesso de leitura, alterando a cópia que o kernel mantém em memória. A partir daí, pode reescrever algo em que o sistema confia e conceder a si próprio acesso root. Em ambientes de container, o mesmo truque que acede ao kernel do host pode aceder ao kernel do nó partilhado por todas as cargas de trabalho.

O padrão vulnerável esteve no código de rede do kernel durante anos, razão pela qual afeta a maioria das versões de kernel suportadas e quase todas as principais distribuições. O Linux corrigiu a falha e todas as distribuições aplicaram o backport, pelo que a correção terá um número de versão diferente em cada uma delas.

Visão geral do Dirty Frag

A Red Hat agrupa três CVEs sob o Dirty Frag. Encontram-se em diferentes áreas do código de rede do kernel, sendo que uma delas é uma variante posterior que a primeira ronda de correções não detetou. Eis como se comparam.

O subsistema indica se isto é relevante para o seu caso. Se não executar VPNs IPsec ou AFS, serve como um sinal rápido para avaliar o nível de importância. O módulo é o que irá verificar para (lsmod | grep -E 'esp4|esp6|rxrpc) para ver o que está carregado.

O Linux mantém dados de ficheiros acedidos recentemente na memória para que não tenha de ler do disco todas as vezes. Essa cópia em memória chama-se page cache. Certas funções do kernel como splice() passam esses dados em cache para o código de rede sem os copiar, fornecendo em vez disso um ponteiro para o local onde os dados já residem. Isso poupa esforço, desde que cada passo subsequente saiba que a memória é partilhada e não escreva nela.

O erro manifestou-se em dois cantos diferentes do código de rede do kernel. Um foi o ESP, que lida com tráfego VPN encriptado. O outro foi o RxRPC, um protocolo mais antigo utilizado principalmente pelo sistema de ficheiros AFS. Nenhum dos caminhos, nem o do ESP nem o do RxRPC, verifica se a memória é partilhada antes de escrever nela.

Isto permitia a um atacante pegar num ficheiro de leitura única que lhe pudesse conceder privilégios se fosse adulterado, algo como /usr/bin/su, e injetar o seu conteúdo no caminho de rede para que a desencriptação vulnerável acabasse por escrever na memória desse ficheiro. A escrita termina na page cache, que é a cópia do ficheiro que o sistema serve a qualquer processo que o leia. O ficheiro no disco nunca muda, mas a versão em memória passa a refletir o que o atacante lá colocou. Executar o su lê a cópia adulterada e concede ao atacante acesso root, mesmo que este apenas tivesse permissão para ler esse ficheiro.

Fragnesia, rastreado como CVE-2026-46300, é a variante mais recente. A correção para o Dirty Frag fez com que o kernel passasse a depender de um marcador que diz "este fragmento é partilhado, faça uma cópia segura antes de lhe tocar". Mas um erro antigo de 2013 no código que junta fragmentos de pacotes remove discretamente esse marcador. Permaneceu inofensivo durante treze anos porque nada dependia dele. Infelizmente, a correção do Dirty Frag dependia dele, o que transformou um erro latente num novo caminho para obter acesso root. 

Porque é que o Dirty Frag é importante para os Container?

Os Container partilham todos um único kernel com o anfitrião (host), pelo que um container comprometido pode aceder ao código vulnerável do kernel se as suas permissões o permitirem (definições de syscall / namespace / política de segurança). Os investigadores já publicaram exploits de prova de conceito funcionais para o Kubernetes, e o Ubuntu detalha o risco de um Escape de container. Se o container conseguir aceder ao kernel, o risco traduz-se em acesso root em todo o nó.

Pode desativar partes do ataque executando cargas de trabalho como não-root (non-root), ativando o perfil seccomp RuntimeDefault, aplicando políticas de pod restritas e limitando os namespaces de utilizadores não privilegiados. No entanto, nada disso corrige a falha real. Apenas a atualização do kernel fornecida pelo fabricante o faz.

Como pode verificar se um anfitrião (host) está exposto?

Comece pelo anfitrião que está efetivamente em execução, e não pelo Dockerfile. Três comandos ajudam.

Execute uname -r para descobrir qual a versão do kernel em execução e, em seguida, compará-la com a versão corrigida no aviso da sua distribuição. Não a compare com o número da árvore principal (upstream). O padrão vulnerável remonta a kernels de cerca de 2017, e as distribuições empresariais e LTS como o RHEL, Ubuntu e Debian aplicam correções retroativas (backport) na versão mais antiga do kernel que já utiliza; logo, um kernel corrigido ainda pode reportar uma versão de anos anteriores. Um anfitrião RHEL 8 totalmente corrigido continuará a indicar 4.18, e esse 4.18 tem a correção aplicada. Confirme com base na versão do pacote corrigido do seu fabricante.

lsmod | grep -E 'esp4|esp6|rxrpc mostra se o caminho de código vulnerável está carregado. Um resultado vazio não significa que esteja totalmente seguro, uma vez que estes módulos são carregados a pedido. E um módulo carregado não é automaticamente prejudicial. O esp4, esp6 e rxrpc são módulos comuns que são perfeitamente seguros num kernel corrigido. Isto indica qual é a sua superfície de ataque e se vale a pena aplicar a mitigação de bloqueio (blacklist).

sysctl user.max_user_namespaces mostra o quão acessível o caminho ESP é. Acima de zero significa que utilizadores sem privilégios podem criar namespaces, a forma habitual de entrar no caminho ESP. Zero fecha essa porta, mas apenas para o ESP. O caminho RxRPC não precisa de namespaces, por isso não está totalmente coberto.

Verifique o estado do seu fornecedor. A Red Hat afirma que o CVE-2026-43500 não afeta os seus produtos, enquanto os CVE-2026-43284 e CVE-2026-46300 afetam os kernels suportados do Red Hat Enterprise Linux e qualquer sistema baseado neles. O Ubuntu publica a versão exata do pacote corrigido para cada linha de kernel que suporta.

O que deve monitorizar?

O código de prova de conceito (PoC) já é público. A Microsoft relatou atividade limitada no mundo real onde um atacante eleva privilégios utilizando su, embora ressalve que isto pode ser o Dirty Frag ou o seu predecessor Copy Fail, uma vez que os dois são difíceis de distinguir apenas através dos registos de processos.

O local realista para detetar isto é nas ferramentas de auditoria e EDR que já utiliza. O framework de auditoria do Linux pode registar a execução de processos e transições setuid, que é onde a sequência reveladora viria ao de cima: um binário desconhecido a ser descarregado e executado, seguido imediatamente por su. Fique atento ao carregamento de esp4, esp6 ou rxrpc por altura de outra atividade suspeita, especialmente num host que não tenha motivos para utilizar IPsec ou AFS, bem como à execução de ficheiros ELF recentemente descarregados. 

Se suspeitar de exploração, execute as suas verificações de integridade a partir de um ambiente de confiança em vez do próprio host possivelmente comprometido. E lembre-se de que bloquear os módulos do kernel não anula quaisquer alterações na cache de páginas que um atacante já tenha feito.

Onde entra o Aikido

A maioria das análises fica-se pela imagem ou pelo repositório. O Dirty Frag vive uma camada abaixo, no kernel que o nó efetivamente arranca.

A varredura de máquinas virtuais do Aikido Security lê o que está realmente instalado no host em execução a partir de um snapshot na cloud, para que um pacote de kernel vulnerável apareça como uma ocorrência no host. Como também associa hosts às workloads e contas que neles correm, pode ver o raio de impacto caso um nó seja comprometido.

Para os hosts na cloud ligados ao Aikido, a varredura de máquinas virtuais deteta os que transportam o pacote de kernel vulnerável e mostra quais as workloads executadas nos mesmos. A correção mantém-se a mesma: aplicar o patch ao kernel do nó e confirmar a build carregada após o reinício.

{{cta}}

FAQ