Fixar em uma tag de release para controle de mudanças: https://raw.githubusercontent.com/haydenjames/dirty-frag-check/v1.0.4/dirty-frag-check.sh.

-q para saída de frota em uma linha. -h para ajuda. Saída 0 ok, 1 vulnerável, 2 desconhecido.

Uso em frota

Os códigos de saída (0 ok, 1 vulnerável, 2 desconhecido) funcionam com qualquer ferramenta que agregue por status.

Requisitos

bash 4+, além dos usuais awk/grep/sed/lsmod/modprobe. Não é necessário root para a verificação em si. Aplicar mitigações exige root.

O que ele verifica

1. Estado dos módulos. Se os módulos implicados pelo aviso — esp4, esp6, ipcomp, ipcomp6 (CVE-2026-43284) e rxrpc (CVE-2026-43500) — estão carregados, disponíveis ou ausentes.
2. Mitigações. Procura por arquivos de blacklist do modprobe e verifica se a blacklist realmente prevalece via modprobe -n -v. Relata o status do SELinux e do AppArmor. Detecta o livepatch do KernelCare via kcarectl --patch-info.
3. Pacote do kernel vs. em execução. Detecta o caso em que você instalou um kernel corrigido mas ainda não reiniciou nele.
4. Kernel em execução vs. versão conhecida como corrigida. Para distribuições da família RHEL (AlmaLinux, Rocky, RHEL, CloudLinux), compara uname -r com a versão corrigida publicada pelo fornecedor para aquela release. Melhor esforço; verifique no rastreador da sua distribuição.

Vereditos

• OK — livepatch do KernelCare aplicado, kernel em execução na/ após a correção publicada, ou todos os módulos relevantes em blacklist.
• MITIGADO — kernel sem correção, mas todos os módulos de alcance estão em blacklist, então o bug não pode ser acionado. Corrija quando puder.
• REINICIALIZAÇÃO NECESSÁRIA — kernel corrigido instalado, você ainda está no antigo.
• VULNERÁVEL — kernel em execução verificado como mais antigo que a correção e uma atualização de kernel está disponível, ou módulos carregados com uma atualização pendente.
• AGUARDANDO CORREÇÃO DO FORNECEDOR — kernel em execução mais antigo que a correção upstream, nenhuma atualização de kernel disponível no momento. Comum no Rocky/CloudLinux ficando uma build atrás do AlmaLinux, ou quando a distribuição faz backport com uma string de versão diferente.
• EM RISCO — host gerenciado pelo KernelCare sem o livepatch do Dirty Frag ainda, ou módulos disponíveis com uma atualização pendente.
• PROVAVELMENTE CORRIGIDO — módulos carregados, mas o kernel em execução está na/ após a correção publicada. O script não consegue inspecionar o nível de correção de um módulo carregado; ele se baseia nos metadados do fornecedor.
• DESCONHECIDO — sem tabela de versões corrigidas para esta distribuição (Ubuntu, Debian, TuxCare ELS) e sem outro sinal forte. Faça verificação cruzada no rastreador da distribuição.

Mitigação provisória

Use isto quando sua distribuição ainda não lançou uma atualização de kernel, ou quando você não pode reiniciar em breve e precisa descarregar os módulos de alcance:

Se o rmmod disser "module is in use", algo na máquina está usando ativamente IPsec ou AF_RXRPC (algumas VPNs, clientes AFS, strongSwan, Libreswan). Não force o descarregamento. Corrija o kernel e reinicie.

Usuários de KernelCare / TuxCare ELS: os livepatches para CVE-2026-43284 cobrem isto sem reinicialização. Verifique kcarectl --patch-info.

Alvos

Voltado para AlmaLinux 8/9/10, Rocky, RHEL, CloudLinux 8/9/10, Ubuntu, Debian e CentOS 7 (TuxCare ELS / KernelCare). A tabela de versões corrigidas é específica da família RHEL; Ubuntu/Debian recorrem à atualidade do gerenciador de pacotes. Confirme qualquer veredito verde no rastreador da sua distribuição.

Discussão

• Aviso do AlmaLinux: Dirty Frag
• CloudLinux / KernelCare: mitigação e atualização de kernel
• cPanel: aviso de segurança
• Tópico do fórum: script de verificação Dirty Frag (linuxcommunity.io)
• Verificador complementar: CVE-2026-31431-check
• Problemas: GitHub

Licença

MIT — veja LICENSE.