// 01 — RESUMENQué es Dirty Frag.
Dirty Frag es una vulnerabilidad CVE-pending de escalamiento local de privilegios en Linux. La investigación describe una cadena que combina dos fallas de escritura en page cache: xfrm-ESP Page-Cache Write y RxRPC Page-Cache Write.
El patrón técnico es familiar para quienes siguieron Dirty Pipe y Copy Fail: una ruta de envío zero-copy con splice() deja una referencia a una página de cache dentro del frag de un sk_buff. Luego, código del kernel realiza criptografía in-place sobre esa memoria, modificando en RAM archivos que el usuario solo podía leer, como /etc/passwd o /usr/bin/su.
Dirty Frag no necesita una ventana de carrera para funcionar. El riesgo operacional sube porque un foothold local puede convertirse en control total del host. BlackDoor Research · 8 de mayo de 2026
// 02 — IMPACTOPor qué importa aunque sea local.
Una LPE local rara vez es el primer paso del ataque. El problema es que suele ser el segundo paso perfecto: después de una webshell, una credencial SSH robada, un job de CI malicioso o un contenedor comprometido.
- Runners self-hosted: un pipeline que ejecuta código de terceros puede dejar de ser un riesgo aislado y convertirse en compromiso del runner.
- Kubernetes y containers: el riesgo depende de la barrera real entre pod y nodo, perfiles seccomp, capacidades, namespaces y kernel compartido.
- Servidores multiusuario: bastiones, hosting compartido, laboratorios y equipos de desarrollo concentran exposición.
- SaaS con ejecución de código: notebooks, sandboxes, evaluadores, plugins y funciones internas deben tratarse como prioridad alta.
- Hosts single-tenant expuestos: si una app puede terminar en RCE, la LPE aumenta el impacto de esa intrusión.
// 03 — PRIORIZACIÓNQué revisar primero.
No todos los Linux pesan igual en el riesgo. Prioriza por probabilidad de ejecución de código no confiable y por impacto de un root local.
- CI/CD self-hosted que ejecute pull requests, builds de proveedores o artefactos no confiables.
- Nodos Kubernetes con workloads de varios equipos, clientes o ambientes compartidos.
- Servidores con cuentas shell, bastiones o acceso de terceros.
- Hosts con IPsec o RxRPC disponible, porque las mitigaciones temporales pueden afectar esos módulos.
- Workstations Linux de administradores con acceso a llaves, kubeconfigs o credenciales de producción.
Regla operacional
Si un host permite ejecutar código que no controla tu equipo de infraestructura, trátalo como prioridad alta hasta tener kernel corregido y reboot confirmado.
// 04 — MITIGACIÓNQué hacer hoy.
La solución correcta es aplicar el kernel corregido de tu distribución y reiniciar. Mientras los backports llegan, las fuentes recomiendan bloquear temporalmente los módulos asociados a la cadena: esp4, esp6 y rxrpc. Esta medida puede romper IPsec o usos legítimos de RxRPC, por lo que debe evaluarse antes de aplicarla masivamente.
- Inventaria kernel activo: valida con
uname -ry no solo con paquetes instalados. - Actualiza desde repos oficiales: Ubuntu, Red Hat, SUSE, Fedora, AlmaLinux, CentOS Stream o tu proveedor.
- Programa reboot o live patch: confirma que el kernel nuevo esté corriendo en cada host crítico.
- Mitiga si no puedes parchar: bloquea módulos vulnerables solo después de revisar impacto en IPsec/VPN y dependencias internas.
# Mitigación temporal reportada por las fuentes públicas
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
# Validar kernel activo después del parcheo
uname -rNo ejecutes PoCs públicos en producción. Si necesitas validar exposición, usa un entorno representativo, aislado y con autorización explícita.
// 05 — VALIDACIÓNQué mirar después.
Después del parche o mitigación, revisa si el servidor pudo haber sido usado durante la ventana vulnerable y reduce la probabilidad de repetir el patrón.
- Procesos y shells: busca shells privilegiadas inesperadas, cambios de UID y ejecución anómala de binarios setuid.
- Logs de CI/CD: revisa jobs no confiables ejecutados desde el 7 de mayo de 2026 en runners persistentes.
- Runtime de containers: verifica perfiles seccomp, capacidades excesivas y pods con permisos de host.
- Módulos cargados: confirma si
esp4,esp6orxrpcestán activos donde no deberían. - Imágenes base: reconstruye runners o nodos efímeros si procesaron código de terceros durante la ventana.