Fija una etiqueta de versión para el control de cambios: https://raw.githubusercontent.com/haydenjames/dirty-frag-check/v1.0.4/dirty-frag-check.sh.

-q para salida de una línea para flotas. -h para ayuda. Salida 0 correcto, 1 vulnerable, 2 desconocido.

Uso en flotas

Los códigos de salida (0 correcto, 1 vulnerable, 2 desconocido) funcionan con cualquier herramienta que agregue por estado.

Requisitos

bash 4+, además de las habituales awk/grep/sed/lsmod/modprobe. No se requiere root para la comprobación en sí. Aplicar mitigaciones sí requiere root.

Qué comprueba

1. Estado de los módulos. Si los módulos implicados por el aviso — esp4, esp6, ipcomp, ipcomp6 (CVE-2026-43284) y rxrpc (CVE-2026-43500) — están cargados, disponibles o ausentes.
2. Mitigaciones. Busca archivos de lista negra de modprobe y verifica que la lista negra realmente prevalece mediante modprobe -n -v. Informa del estado de SELinux y AppArmor. Detecta el livepatch de KernelCare mediante kcarectl --patch-info.
3. Paquete del kernel vs. en ejecución. Detecta el caso en el que has instalado un kernel parcheado pero no has reiniciado con él.
4. Kernel en ejecución vs. versión corregida conocida. Para distribuciones de la familia RHEL (AlmaLinux, Rocky, RHEL, CloudLinux), compara uname -r con la versión corregida publicada por el proveedor para esa versión. Con la mejor intención; verifica contra el rastreador de tu distribución.

Veredictos

• OK — Livepatch de KernelCare aplicado, kernel en ejecución en/después de la corrección publicada, o todos los módulos relevantes en lista negra.
• MITIGADO — el kernel no está parcheado pero todos los módulos de acceso están en lista negra, por lo que el fallo no puede activarse. Parchea cuando puedas.
• REINICIO NECESARIO — kernel parcheado instalado, sigues con el antiguo.
• VULNERABLE — kernel en ejecución verificado como anterior a la corrección y hay una actualización de kernel disponible, o módulos cargados con una actualización pendiente.
• ESPERANDO PARCHE DEL PROVEEDOR — kernel en ejecución anterior a la corrección upstream, sin actualización de kernel disponible actualmente. Común en Rocky/CloudLinux que van una compilación por detrás de AlmaLinux, o cuando la distribución hace backport con una cadena de versión diferente.
• EN RIESGO — host gestionado por KernelCare sin el livepatch de Dirty Frag todavía, o módulos disponibles con una actualización pendiente.
• PROBABLEMENTE PARCHEADO — módulos cargados pero el kernel en ejecución está en/después de la corrección publicada. El script no puede inspeccionar el nivel de parche de un módulo cargado; se remite a los metadatos del proveedor.
• DESCONOCIDO — sin tabla de versiones corregidas para esta distribución (Ubuntu, Debian, TuxCare ELS) y sin otra señal sólida. Contrasta con el rastreador de la distribución.

Mitigación provisional

Úsala cuando tu distribución aún no haya publicado una actualización del kernel, o cuando no puedas reiniciar pronto y necesites descargar los módulos de acceso:

Si rmmod dice "module is in use", algo en el equipo usa activamente IPsec o AF_RXRPC (algunas VPN, clientes AFS, strongSwan, Libreswan). No lo fuerces a descargar. Parchea el kernel y reinicia en su lugar.

Usuarios de KernelCare / TuxCare ELS: los livepatches para CVE-2026-43284 cubren esto sin reinicio. Comprueba kcarectl --patch-info.

Objetivos

Orientado a AlmaLinux 8/9/10, Rocky, RHEL, CloudLinux 8/9/10, Ubuntu, Debian y CentOS 7 (TuxCare ELS / KernelCare). La tabla de versiones corregidas es específica de la familia RHEL; Ubuntu/Debian recurren a la actualidad del gestor de paquetes. Confirma cualquier veredicto verde contra el rastreador de tu distribución.

Discusión

• Aviso de AlmaLinux: Dirty Frag
• CloudLinux / KernelCare: mitigación y actualización del kernel
• cPanel: aviso de seguridad
• Hilo del foro: script de comprobación de Dirty Frag (linuxcommunity.io)
• Comprobador complementario: CVE-2026-31431-check
• Incidencias: GitHub

Licencia

MIT — consulta LICENSE.