a black and white sign with white letters
Pesquisar
Instagram Linkedin Facebook Soundcloud Youtube Discord

Dirty Frag: O Novo Zero-Day que Concede Root no Linux com um Único Comando — CVE-2026-43284 e CVE-2026-43500

Facebook Youtube Instagram Soundcloud Envelope

Apenas uma semana após a comunidade Linux ainda estar aplicando patches para a vulnerabilidade Copy Fail (CVE-2026-31431), uma nova ameaça de escalonamento de privilégios local emergiu com impacto potencialmente ainda mais devastador. Em 7 de maio de 2026, o pesquisador de segurança Hyunwoo Kim (@v4bel) divulgou publicamente a vulnerabilidade batizada de Dirty Frag — um exploit que encadeia duas falhas distintas no kernel Linux para permitir que qualquer usuário local sem privilégios obtenha acesso root em praticamente todas as principais distribuições Linux com um único comando.

A divulgação ocorreu de forma antecipada e turbulenta: um terceiro não relacionado quebrou o embargo de divulgação responsável antes que patches e CVEs estivessem prontos, forçando Kim — com o acordo dos mantenedores das distribuições — a publicar toda a documentação técnica e o proof-of-concept (PoC) funcional simultaneamente. O resultado foi uma tempestade perfeita: exploit público disponível antes de qualquer patch oficial das distribuições, afetando sistemas que estão em produção há quase uma década.

Aqui no Blog Dolutech, tratamos esta situação com a urgência que ela merece. Este artigo oferece uma análise técnica completa da Dirty Frag, incluindo o funcionamento detalhado de ambas as vulnerabilidades, a cadeia de exploração, como verificar se seu sistema está vulnerável, como aplicar mitigações imediatas, como verificar se os patches já foram aplicados, e as lições fundamentais para administradores de sistemas e profissionais de segurança.

O que é a Dirty Frag?

A Dirty Frag é uma vulnerabilidade de escalonamento de privilégios local (LPE — Local Privilege Escalation) no kernel Linux que permite a um usuário local sem privilégios modificar arquivos protegidos do sistema diretamente na memória RAM (page cache) e obter acesso root. A vulnerabilidade foi classificada com CVSS 7.8 (severidade Alta) e pertence à mesma classe de bugs das conhecidas Dirty Pipe (CVE-2022-0847) e Copy Fail (CVE-2026-31431), porém explora um campo diferente da estrutura de dados do kernel — o campo frag do struct sk_buff, a estrutura que o kernel Linux usa para representar pacotes de rede.

O nome “Dirty Frag” é uma referência direta a esse mecanismo: a vulnerabilidade “suja” (dirty) o campo frag (fragmento) dos buffers de socket do kernel, permitindo a modificação não autorizada do page cache de arquivos do sistema.

A Dirty Frag é composta por duas vulnerabilidades independentes que, quando encadeadas, cobrem as limitações uma da outra e funcionam em todas as principais distribuições Linux:

CVE-2026-43284 — vulnerabilidade de escrita no page cache via interface xfrm-ESP (subsistema de criptografia IPsec). Esta falha foi introduzida em janeiro de 2017 pelo commit cac2661c53f3, que moveu o recebimento do IPsec ESP para um caminho rápido de descriptografia in-place. Ela fornece uma primitiva de escrita arbitrária de 4 bytes no page cache, mas requer privilégio para criar user namespaces (CAP_NET_ADMIN).

CVE-2026-43500 — vulnerabilidade de escrita no page cache via interface RxRPC (protocolo usado pelo Andrew File System — AFS). Esta falha foi introduzida em junho de 2023 pelo commit 2dc334f1a63a. Ela fornece uma primitiva de escrita de 8 bytes no page cache e não requer privilégio de namespace, mas depende do módulo rxrpc.ko estar disponível no sistema.

A genialidade do encadeamento é que cada variante cobre o “ponto cego” da outra. Em distribuições como RHEL, CentOS e Fedora, onde a criação de user namespaces é permitida mas o módulo rxrpc não está incluído, a variante ESP funciona. No Ubuntu, onde a criação de user namespaces é bloqueada pelo AppArmor mas o módulo rxrpc.ko está incluído por padrão, a variante RxRPC funciona. Juntas, elas garantem escalação para root em todas as grandes distribuições.

A Causa Raiz Técnica

O Linux mantém arquivos lidos recentemente em RAM como cache de performance (o chamado “page cache”). Quando você lê /usr/bin/su, o kernel não vai ao disco — serve os bytes diretamente da memória. Crucialmente, este cache é compartilhado: todo processo que abre o mesmo arquivo aponta para as mesmas páginas de memória. As permissões de arquivo determinam quem pode modificar essas páginas, e normalmente um usuário sem privilégios não pode.

Dois recursos de rede do Linux — a criptografia IPsec (ESP) e o protocolo de compartilhamento de arquivos RxRPC — utilizam uma otimização que descriptografa dados recebidos “in-place” (no mesmo local). Em vez de copiar os dados de rede recebidos para um buffer novo antes da descriptografia, o kernel descriptografa diretamente na memória onde os dados chegaram.

A falha fundamental é que o kernel não verifica quem realmente é o dono daquela memória. Isso significa que um atacante pode costurar um pacote de rede falso cujo payload de memória é secretamente uma página emprestada do cache do /usr/bin/su. O atacante configura a descriptografia do kernel usando sua própria chave, de modo que a “saída descriptografada” são os bytes que ele escolheu completamente. Como resultado, o kernel obedientemente escreve esses bytes na página emprestada — que é a cópia em memória do arquivo su que todo o sistema compartilha. Agora /usr/bin/su está silenciosamente reescrito na RAM com o shellcode do atacante. A próxima pessoa que executar su executa o código do atacante como root.

Como Funciona a Exploração — Cadeia de Ataque

Variante ESP (CVE-2026-43284): Reescrita de /usr/bin/su

O exploit da variante ESP visa o arquivo /usr/bin/su. Os primeiros 192 bytes do page cache de /usr/bin/su (que possui o bit setuid-root) são inteiramente substituídos por um ELF estático mínimo que executa um root shell. O novo ELF mapeia 0xB8 bytes no endereço virtual 0x400000 como R+X via PT_LOAD, e no entry point 0x400078 executa setgid(0); setuid(0); setgroups(0, NULL); execve("/bin/sh", NULL, ["TERM=xterm", NULL]). O fluxo PAM é completamente bypassed, e um único execve("/usr/bin/su") é suficiente para obter um root shell.

Os 192 bytes são divididos em 48 chunks de 4 bytes cada, escritos via a primitiva de STORE arbitrário de 4 bytes da variante ESP. O processo de exploração segue estas etapas: o exploit cria um processo filho isolado em um novo user/net namespace via unshare(CLONE_NEWUSER | CLONE_NEWNET), obtendo root dentro desse namespace. Registra 48 XFRM SAs (Security Associations) de uma vez, cada uma com um SPI separado e os 4 bytes do shellcode posicionados no campo seq_hi do XFRMA_REPLAY_ESN_VAL. Para cada chunk, usa vmsplice para inserir o cabeçalho ESP forjado em um pipe, depois splice para inserir 16 bytes do page cache de /usr/bin/su no próximo slot do pipe, e finalmente splice para enviar tudo via socket UDP configurado com ESP encapsulation para o loopback.

O skb (socket buffer) recebido no loopback chega com o page cache page P de /usr/bin/su plantado como fragmento (frag[0]). O branch vulnerável em esp_input() pula a chamada skb_cow_data() quando o skb não é clonado e não tem frag_list, realizando a descriptografia in-place diretamente sobre a página do page cache. O STORE de 4 bytes acontece em crypto_authenc_esn_decrypt() durante o passo de pré-processamento que move os 4 bytes de ordem superior do número de sequência para o final do SGL. Embora a verificação de autenticação AEAD falhe com -EBADMSG, o STORE já aconteceu e a modificação no page cache persiste.

Ciclando i de 0 a 47, o ELF de 192 bytes é completamente montado sobre o page cache. A operação é determinística — não há race condition. Quando o processo pai executa /usr/bin/su -, a cópia modificada é mapeada no novo processo, o bit setuid-root eleva para euid=0, e o shellcode no entry point executa /bin/sh com privilégios root.

Variante RxRPC (CVE-2026-43500): Modificação de /etc/passwd

A variante RxRPC não requer unshare() e funciona com APIs disponíveis a usuários sem privilégios: add_key(), socket(AF_RXRPC), socket(AF_ALG), splice() e recvmsg().

Em vez de reescrever /usr/bin/su, esta variante visa a linha 1 (entrada root) de /etc/passwd. A linha original "root:x:0:0:root:/root:/bin/bash" é modificada para "root::0:0:GGGGGG:/root:/bin/bash" — o campo de senha se torna uma string vazia, e o módulo pam_unix.so nullok do PAM aceita isso sem solicitar senha.

O STORE de 8 bytes é o resultado de fcrypt_decrypt(C, K), onde C é o ciphertext na posição alvo e K é a chave de sessão que o atacante planta na chave RxRPC. O atacante faz brute-force em user-space (usando uma porta do crypto/fcrypt.c do kernel, ~18 milhões de tentativas por segundo) até encontrar a chave K que produz o plaintext desejado. O exploit usa três STOREs posicionados em last-write-wins para reformar os caracteres 4 a 15 da primeira linha do /etc/passwd.

O Encadeamento Universal

O exploit binário único tenta primeiro a variante ESP em um processo filho. Se falhar (por exemplo, se unshare(USER) retorna -EPERM no Ubuntu, ou se esp4.ko não está carregado), faz fallback para a variante RxRPC. Isso garante que um único exploit funcione em todas as principais distribuições.

Distribuições Afetadas

A Dirty Frag foi testada e confirmada nas seguintes distribuições e versões de kernel:

Ubuntu 24.04.4 (kernel 6.17.0-23-generic), Red Hat Enterprise Linux 10.1 (kernel 6.12.0-124.49.1.el10_1.x86_64), openSUSE Tumbleweed (kernel 7.0.2-1-default), CentOS Stream 10 (kernel 6.12.0-224.el10.x86_64), AlmaLinux 10 (kernel 6.12.0-124.52.3.el10_1.x86_64) e Fedora 44 (kernel 6.19.14-300.fc44.x86_64).

A falha ESP (CVE-2026-43284) existe no kernel desde janeiro de 2017, e a falha RxRPC (CVE-2026-43500) desde junho de 2023. Na prática, distribuições Linux lançadas nos últimos 9 anos são provavelmente afetadas. Todas as versões do Ubuntu (de 14.04 LTS a 26.04 LTS), RHEL 8, 9 e 10, OpenShift 4, Debian, Amazon Linux, SUSE, Rocky Linux, CloudLinux e virtualmente todas as outras distribuições baseadas no kernel Linux estão no escopo.

Exploração Ativa Já Observada

A Microsoft anunciou em 8 de maio de 2026 que está observando exploração ativa limitada onde escalação de privilégios via o comando su é observada, e que “pode ser indicativa de técnicas associadas com ‘Dirty Frag’ ou ‘Copy Fail'”.

De acordo com o relatório da Microsoft, a campanha observada mostra um timeline de ataque sequencial: uma conexão externa ganha acesso SSH e spawna um shell interativo, seguido pelo staging e execução de um binário ELF (./update) que imediatamente dispara escalação de privilégios via su. Após obter acesso elevado, o ator modifica um arquivo de autenticação LDAP do GLPI, realiza reconhecimento do diretório GLPI e configuração do sistema, e inspeciona um artefato de exploit. A atividade então muda para acesso a dados sensíveis e interação com arquivos de sessão PHP — deletando múltiplos arquivos de sessão e depois limpando forçadamente arquivos adicionais — antes de ler dados de sessão remanescentes.

Como Verificar se Seu Sistema está Vulnerável

O Blog Dolutech recomenda os seguintes passos para determinar se seu sistema está vulnerável à Dirty Frag:

Passo 1: Verificar a versão do kernel

Execute o seguinte comando para verificar sua versão atual do kernel:

uname -r

Compare o resultado com as versões corrigidas listadas na seção de patches abaixo. Se sua versão for anterior às versões corrigidas, seu sistema está vulnerável.

Passo 2: Verificar se os módulos vulneráveis estão carregados

lsmod | grep -E 'esp4|esp6|rxrpc'

Se qualquer um desses módulos aparecer na saída, eles estão atualmente carregados e seu sistema possui a superfície de ataque ativa. Se nenhum módulo aparecer, a superfície de ataque imediata é reduzida, mas os módulos podem ser carregados automaticamente por qualquer processo.

Passo 3: Verificar se os módulos estão disponíveis no sistema

Mesmo que os módulos não estejam carregados, verifique se eles estão disponíveis para carregamento:

find /lib/modules/$(uname -r) -name "esp4.ko*" -o -name "esp6.ko*" -o -name "rxrpc.ko*"

Se os arquivos existirem, os módulos podem ser carregados automaticamente sob demanda, e o sistema permanece vulnerável.

Passo 4: Verificar se a mitigação já foi aplicada

cat /etc/modprobe.d/dirtyfrag.conf 2>/dev/null

Se o arquivo existir e contiver as linhas install esp4 /bin/false, install esp6 /bin/false e install rxrpc /bin/false, a mitigação de blacklist está aplicada. Confirme que os módulos não estão carregados:

grep -qE '^(esp4|esp6|rxrpc) ' /proc/modules && echo "ALERTA: Módulos afetados ESTÃO carregados - sistema vulnerável" || echo "OK: Módulos afetados NÃO estão carregados"

Passo 5: Verificar se o sistema usa IPsec ou AFS

Antes de aplicar a mitigação, é crítico verificar se seu sistema depende dos módulos que serão desabilitados:

Para verificar uso de IPsec:

# Verificar se existem SAs (Security Associations) configuradas
ip xfrm state list
ip xfrm policy list

# Verificar se StrongSwan ou Libreswan está em execução
systemctl status strongswan 2>/dev/null
systemctl status ipsec 2>/dev/null

# Verificar se existem túneis VPN IPsec ativos
ip tunnel show

Para verificar uso de AFS/RxRPC:

# Verificar se o AFS está em uso
lsmod | grep openafs
mount | grep afs
systemctl status openafs-client 2>/dev/null

Se nenhum desses comandos retornar resultados indicando uso ativo, é seguro aplicar a mitigação de blacklist.

Como Aplicar a Mitigação Imediata (Sem Patch)

Se os patches ainda não estão disponíveis para sua distribuição ou se você não pode reiniciar imediatamente, aplique a seguinte mitigação de emergência:

Mitigação Padrão: Blacklist dos Módulos Vulneráveis

Este é o método recomendado para a maioria dos sistemas que não utilizam IPsec ou AFS:

sudo sh -c "printf 'install esp4 /bin/false\ninstall esp6 /bin/false\ninstall rxrpc /bin/false\n' > /etc/modprobe.d/dirtyfrag.conf; rmmod esp4 esp6 rxrpc 2>/dev/null; true"

Este comando realiza duas ações: cria um arquivo de configuração do modprobe que impede os três módulos de serem carregados, e tenta descarregá-los se já estiverem carregados (o rmmod é best-effort e silencioso se o módulo não estiver presente).

Limpar o Page Cache

O exploit Dirty Frag funciona corrompendo páginas do page cache de arquivos sensíveis (como /etc/passwd ou /usr/bin/su). Se você suspeita que o sistema pode ter sido alvo antes da aplicação da mitigação, limpe o page cache:

sudo sh -c 'echo 3 > /proc/sys/vm/drop_caches'

Este comando é seguro para executar em um sistema em produção — ele apenas libera cache limpo e entradas de dentry/inode. Pode causar um aumento temporário de I/O de disco.

Para Ubuntu: Regenerar o initramfs

No Ubuntu, a Canonical recomenda passos adicionais para garantir que os módulos não sejam carregados durante o boot inicial:

# Passo 1: Criar o arquivo de bloqueio
echo "install esp4 /bin/false" | sudo tee /etc/modprobe.d/dirty-frag.conf
echo "install esp6 /bin/false" | sudo tee -a /etc/modprobe.d/dirty-frag.conf
echo "install rxrpc /bin/false" | sudo tee -a /etc/modprobe.d/dirty-frag.conf

# Passo 2: Regenerar o initramfs
sudo update-initramfs -u -k all

# Passo 3: Descarregar os módulos
sudo rmmod esp4 esp6 rxrpc 2>/dev/null

# Passo 4: Confirmar que os módulos não estão carregados
grep -qE '^(esp4|esp6|rxrpc) ' /proc/modules && echo "ALERTA: Módulos ainda carregados - reboot necessário" || echo "OK: Módulos não estão carregados"

Mitigação Alternativa para Ambientes que Usam IPsec

Se seu ambiente requer que o IPsec continue funcional, a variante ESP (CVE-2026-43284) pode ser bloqueada desabilitando user namespaces sem privilégios:

echo "user.max_user_namespaces=0" | sudo tee /etc/sysctl.d/dirtyfrag.conf
sudo sysctl --system

Atenção: Isso bloqueia apenas a variante ESP. No RHEL 9/10, a variante RxRPC (CVE-2026-43500) permanece explorável a menos que o rxrpc também seja bloqueado. Além disso, desabilitar user namespaces pode afetar containers rootless, navegadores sandboxed e Flatpak.

Status dos Patches por Distribuição (Atualizado em 09/05/2026)

Patches Disponíveis

AlmaLinux — Patches em produção desde 08/05/2026:

  • AlmaLinux 8: kernel-4.18.0-553.123.2.el8_10 ou superior
  • AlmaLinux 9: kernel-5.14.0-611.54.3.el9_7 ou superior
  • AlmaLinux 10: kernel-6.12.0-124.55.2.el10_1 ou superior
sudo dnf clean metadata && sudo dnf upgrade
sudo reboot

CloudLinux — Patches disponíveis:

  • CL7h: kernel-4.18.0-553.123.2.lve.el7h ou superior
  • CL8: kernel-4.18.0-553.123.2.lve.el8 ou superior
  • CL9/CL10: Via kernel AlmaLinux (versões acima)
  • LTS kernel: dnf update 'kernel-lts*' --enablerepo=cloudlinux-updates-testing && reboot

Kernel Mainline — Patch para CVE-2026-43284 merged em f4c50a4034e62ab75f1d5cdd191dd5f9c77fdff4

SUSE — Advisory SUSE-2026-1778-1 publicada para SUSE Linux Enterprise 15 SP7 RT

Amazon Linux — Security bulletin AWS-2026-027 publicado

Patches Pendentes ou Em Progresso

Red Hat Enterprise Linux — Advisory RHSB-2026-003 publicada; patches em desenvolvimento para RHEL 8, 9, 10 e OpenShift 4. SELinux em modo enforcing fornece proteção adicional.

Ubuntu/Canonical — Todas as releases (14.04 a 26.04 LTS) listadas como afetadas; patches de kernel em preparação. Mitigação manual disponível.

Debian — Tracker de segurança ativo para ambos CVEs; patches em preparação.

CVE-2026-43500 (RxRPC) — Nenhum patch disponível em nenhuma tree upstream no momento da escrita. O patch proposto por Hyunwoo Kim está na mailing list do netdev.

Como Verificar se o Patch Foi Aplicado

Verificação por versão do kernel

Após atualizar e reiniciar:

uname -r

Compare com as versões corrigidas da sua distribuição listadas acima.

Verificação por pacote RPM (RHEL/CentOS/AlmaLinux/Fedora)

rpm -q kernel | sort -V

Verifique se a versão instalada é igual ou superior à versão corrigida.

Verificação por pacote DEB (Ubuntu/Debian)

dpkg -l | grep linux-image

Verificação do KernelCare (CloudLinux)

Se utiliza KernelCare livepatch:

kcarectl --info
kcarectl --update

Verificação abrangente

Para uma verificação completa que confirme se seu sistema está protegido:

echo "=== Versão do Kernel ==="
uname -r

echo ""
echo "=== Status dos Módulos Vulneráveis ==="
for mod in esp4 esp6 rxrpc; do
    if grep -q "^${mod} " /proc/modules; then
        echo "ALERTA: Módulo ${mod} está CARREGADO"
    else
        echo "OK: Módulo ${mod} NÃO está carregado"
    fi
done

echo ""
echo "=== Mitigação Blacklist ==="
if [ -f /etc/modprobe.d/dirtyfrag.conf ] || [ -f /etc/modprobe.d/dirty-frag.conf ]; then
    echo "OK: Arquivo de mitigação encontrado:"
    cat /etc/modprobe.d/dirtyfrag.conf 2>/dev/null
    cat /etc/modprobe.d/dirty-frag.conf 2>/dev/null
else
    echo "AVISO: Nenhum arquivo de mitigação encontrado"
fi

echo ""
echo "=== Verificação Final ==="
grep -qE '^(esp4|esp6|rxrpc) ' /proc/modules
if [ $? -eq 0 ]; then
    echo "RESULTADO: Sistema VULNERÁVEL - módulos afetados carregados"
else
    echo "RESULTADO: Superfície de ataque reduzida - módulos não carregados"
fi

Como Aplicar o Patch de Segurança

Para AlmaLinux 8, 9 e 10

# Atualizar metadata e instalar patch
sudo dnf clean metadata
sudo dnf upgrade kernel*

# Reiniciar para carregar o novo kernel
sudo reboot

# Após reinício, verificar versão
uname -r

# Remover mitigação temporária (se aplicada)
sudo rm -f /etc/modprobe.d/dirtyfrag.conf

Para CloudLinux 7h e 8

# Instalar kernel corrigido do canal estável
sudo yum install --enablerepo=cloudlinux-rollout-4-bypass kernel*
sudo reboot

# Verificar
uname -r

Para CloudLinux 9 e 10 (via AlmaLinux)

sudo dnf update 'kernel*'
sudo reboot
uname -r

Para RHEL / CentOS Stream

Aguardar os patches oficiais da Red Hat (RHSB-2026-003). Enquanto isso, aplicar a mitigação de blacklist. Quando os patches forem publicados:

sudo dnf update kernel*
sudo reboot
uname -r

# Remover mitigação
sudo rm -f /etc/modprobe.d/dirtyfrag.conf

Para Ubuntu / Debian

Quando os patches forem publicados pela Canonical/Debian:

sudo apt update
sudo apt upgrade linux-image-$(uname -r)
sudo reboot

# Verificar
uname -r

# Remover mitigação e regenerar initramfs
sudo rm -f /etc/modprobe.d/dirty-frag.conf
sudo update-initramfs -u -k all

Para SUSE / openSUSE

sudo zypper refresh
sudo zypper update kernel-default
sudo reboot
uname -r

Para KernelCare (livepatch sem reboot)

Se sua organização usa KernelCare da CloudLinux, o livepatch pode ser aplicado sem reinicialização:

kcarectl --update
kcarectl --info

Livepatches estão disponíveis para distribuições EL8 (CentOS 8, RHEL 8, AlmaLinux 8, CloudLinux 8, CloudLinux 7 Hybrid) e AlmaLinux 9 FIPS.

O Que Fazer Se Seu Sistema Já Foi Comprometido

Se você suspeita que o exploit Dirty Frag foi utilizado no seu sistema antes da aplicação da mitigação, siga estes passos de resposta a incidentes:

Primeiro, aplique a mitigação de blacklist imediatamente (comando acima). Em seguida, limpe o page cache para evictar quaisquer páginas corrompidas:

sudo sh -c 'echo 3 > /proc/sys/vm/drop_caches'

Verifique a integridade dos binários críticos do sistema:

# Para sistemas RPM (RHEL, CentOS, AlmaLinux, Fedora)
rpm -Va --nomtime 2>/dev/null | grep -E '(su|passwd|sudo|login)'

# Para sistemas DEB (Ubuntu, Debian)
debsums -c 2>/dev/null | grep -E '(su|passwd|sudo|login)'

Verifique o arquivo /etc/passwd para modificações suspeitas:

# Verificar se a linha root tem campo de senha vazio
head -1 /etc/passwd
# A saída normal deve ser: root:x:0:0:root:/root:/bin/bash
# Se for: root::0:0:... (campo vazio após root:), o sistema foi comprometido

Verifique o /etc/shadow para alterações:

sudo head -1 /etc/shadow

Verifique logs de autenticação recentes para atividade suspeita:

grep -i 'su\|sudo\|authentication' /var/log/auth.log 2>/dev/null | tail -50
journalctl -u sshd --since "2026-05-07" 2>/dev/null | tail -50

Se evidências de comprometimento forem encontradas, considere: restaurar /etc/passwd e /usr/bin/su a partir de backups ou reinstalar os pacotes relevantes; rotacionar todas as credenciais do sistema; e conduzir uma investigação forense completa.

Detecção em Runtime

Regra Falco para Detecção de Socket AF_RXRPC

Para organizações que utilizam Falco para detecção em runtime, a seguinte regra detecta a criação de sockets AF_RXRPC por processos inesperados — um indicador precoce da variante RxRPC do exploit:

- rule: AF_RXRPC Socket Created by Unexpected Process
  desc: >
    Detecta criação de socket AF_RXRPC (domínio 33) por processo não-AFS.
    Indicador do caminho de exploit RxRPC do Dirty Frag.
  condition: >
    evt.type=socket and evt.dir=< and evt.rawres >= 0 and
    (evt.rawarg.domain=33 or evt.arg.domain contains AF_RXRPC) and
    proc_name_exists and
    not proc.name in (af_rxrpc_trusted_processes)
  output: Socket AF_RXRPC criado por processo inesperado
    (proc.name=%proc.name proc.exepath=%proc.exepath
     proc.cmdline=%proc.cmdline proc.pid=%proc.pid)

Detecções Microsoft Defender

A Microsoft publicou as seguintes assinaturas de detecção: Exploit:Linux/DirtyFrag.A, Exploit:Linux/DirtyFrag.B, Trojan:Linux/DirtyFrag.Z!MTB, Trojan:Linux/DirtyFrag.ZA!MTB, Trojan:Linux/DirtyFrag.ZC!MTB e Trojan:Linux/DirtyFrag.DA!MTB.

Comparação com Vulnerabilidades Anteriores

A Dirty Frag se insere em uma linhagem de vulnerabilidades de page cache no kernel Linux que têm se tornado cada vez mais sofisticadas:

Dirty Cow (CVE-2016-5195, 2016) dependia de vencer uma race condition, o que tornava a exploração frequentemente não-confiável.

Dirty Pipe (CVE-2022-0847, 2022) tinha restrições sobre como os dados podiam ser escritos e onde em um arquivo podiam ser modificados.

Copy Fail (CVE-2026-31431, abril 2026) introduziu uma primitiva de escrita de 4 bytes no page cache via o subsistema algif_aead, adicionada ao catálogo KEV da CISA em 01/05/2026.

Dirty Frag (CVE-2026-43284/43500, maio 2026) é o membro mais recente e mais versátil desta classe, com exploração determinística (sem race condition), taxa de sucesso muito alta, sem kernel panic em caso de falha, e funcionamento universal em todas as grandes distribuições através do encadeamento de variantes complementares. Criticamente, a Dirty Frag funciona mesmo em sistemas onde a mitigação do Copy Fail (blacklist de algif_aead) foi aplicada.

Recomendações do Blog Dolutech

O Blog Dolutech sintetiza as seguintes recomendações prioritárias:

Ação imediata (hoje): Aplique a mitigação de blacklist dos módulos esp4, esp6 e rxrpc em todos os servidores Linux. Verifique se seu sistema usa IPsec antes de aplicar. Limpe o page cache após aplicar a mitigação.

Ação de curto prazo (próximos dias): Monitore os avisos de segurança da sua distribuição e aplique os patches de kernel assim que disponíveis. Reinicie após a atualização do kernel. Remova a mitigação temporária após confirmar que o kernel corrigido está ativo.

Ação de médio prazo: Implemente detecção em runtime (Falco, Sysdig, Microsoft Defender) para identificar tentativas de exploração. Restrinja syscalls AF_KEY, AF_RXRPC e XFRM netlink em ambientes containerizados via perfis seccomp. Audite workloads para identificar uso legítimo de IPsec e AFS. Monitore modificações inesperadas em binários setuid e /etc/passwd.

Lição estratégica: A classe de bugs page-cache-write deve ser tratada como um padrão recorrente, não como um bug isolado. Dirty Pipe, Copy Fail e Dirty Frag são todos membros da mesma família, e é razoável esperar que mais variantes sejam descobertas no futuro.

Conclusão

A Dirty Frag representa a segunda vulnerabilidade universal de escalonamento de privilégios local no Linux em apenas oito dias, seguindo o Copy Fail. Ambas transformam otimizações de processamento in-place de longa data em primitivas determinísticas de acesso root: uma no crypto userspace, outra no recebimento IPsec. Com um PoC funcional público lançado antes dos patches e a exploração reduzida a um punhado de syscalls padrão, defensores devem assumir que qualquer ponto de apoio local em um host não-patcheado pode se tornar root em segundos.

Aqui no Blog Dolutech, enfatizamos que esta não é uma ameaça teórica — a Microsoft já confirmou exploração ativa limitada. A aplicação imediata da mitigação, seguida pela instalação dos patches assim que disponíveis, é absolutamente imperativa para qualquer organização que opera servidores Linux.

Fique atento às atualizações do Blog Dolutech para as últimas informações sobre esta e outras ameaças críticas de segurança.

Referências e Fontes

Conheça nosso Canal do Youtube
Escute Nosso DoluCast
Melhores da Semana