Dirty Frag: la vulnerabilidad determinista de Linux que permite obtener root con un solo comando

Han emergido detalles de una nueva vulnerabilidad local de escalada de privilegios en el kernel de Linux apodada Dirty Frag, que combina dos fallos de escritura en la caché de páginas para obtener privilegios root sin necesidad de condiciones de carrera. Según la investigación publicada por Hyunwoo Kim, la explotación encadena una vulnerabilidad en el subsistema IPSec (xfrm‑ESP Page‑Cache Write) con otra en RxRPC (RxRPC Page‑Cache Write), y su naturaleza es determinista, sin depender de ventanas de tiempo, lo que eleva significativamente la tasa de éxito y la seriedad del riesgo para sistemas sin parchear.

El problema es especialmente relevante porque toca caminos de recepción en los que el kernel descifra directamente sobre páginas que en realidad están referenciadas por procesos de usuario (por ejemplo, páginas de pipe adjuntadas mediante splice/sendfile o MSG_SPLICE_PAGES), lo que puede exponer o corromper texto plano que un proceso no privilegiado aún mantiene. La combinación cubre escenarios complementarios: en distribuciones que permiten la creación de namespaces de usuario el ataque IPSec puede ejecutarse, mientras que en Ubuntu —donde la creación de namespaces está bloqueada por AppArmor— el módulo rxrpc, cargado por defecto, hace posible la otra variante. Esto significa que muchas distribuciones populares están expuestas (mencionadas entre ellas Ubuntu 24.04.4, RHEL 10.1, Fedora 44, CentOS Stream 10, AlmaLinux 10 y openSUSE Tumbleweed), y además existe ya una prueba de concepto funcional que permite obtener root con un único comando, lo que incrementa la urgencia.

Desde el punto de vista histórico, los vectores implicados recuerdan a fallos previos de la familia Dirty Pipe y Copy Fail, pero Dirty Frag no depende del módulo algif_aead ni de sus mitigaciones conocidas, por lo que sistemas previamente "parcheados" contra Copy Fail pueden seguir siendo vulnerables. Además, las raíces del problema se remontan a commits del kernel de 2017 y 2023, lo que subraya cómo cambios antiguos pueden habilitar cadenas nuevas y peligrosas años después.

Mientras los mantenedores del kernel trabajan en parches, las medidas de mitigación temporales son críticas para reducir la superficie de ataque en servidores y estaciones de trabajo expuestos a usuarios locales o a entornos multiusuario. Entre las acciones más efectivas y de bajo riesgo está evitar que se carguen los módulos afectados (esp4, esp6 y rxrpc) hasta que llegue un parche oficial; esto se puede lograr creando reglas en /etc/modprobe.d/ que impidan la carga automática del módulo o que redirijan su instalación a /bin/false, y verificando la ausencia con lsmod. Otra mitigación complementaria es deshabilitar la clonación de namespaces por usuarios no privilegiados (sysctl kernel.unprivileged_userns_clone=0), y en entornos Ubuntu comprobar la política de AppArmor porque en muchos casos impide el primer vector (xfrm) al bloquear la creación de user namespaces. Para más detalle sobre cómo y dónde gestionar la carga de módulos consulte la documentación oficial del kernel en Kernel.org — administración de módulos y la documentación de AppArmor que mantiene Canonical en Ubuntu — AppArmor.

Es importante planificar estas mitigaciones con criterio operativo: bloquear módulos vinculados a IPSec o RxRPC puede tener impacto funcional en servicios que dependen de IPSec/ESP o del núcleo de RxRPC, por lo que debe evaluarse el efecto en aplicaciones y conectividad antes de aplicar cambios en producción. Asimismo, mantenga controles de acceso a cuentas locales, restrinja la posibilidad de subir y ejecutar binarios por usuarios no confiables, audite cambios en ficheros SUID/SGID y monitorice señales de explotación (creación de shells con privilegios, cargas inusuales de módulos, actividad de procesos desconocidos).

Finalmente, cuando los parches oficiales estén disponibles, aplíquelos con prioridad y verifique que el kernel actualizado efectivamente corrige las referencias implicadas. A largo plazo, este incidente vuelve a poner de manifiesto la necesidad de minimizar el attack surface en hosts expuestos: deshabilitar módulos innecesarios, aplicar principios de menor privilegio para usuarios locales y mantener imágenes base lo más simples posible reduce la probabilidad de que cadenas como Dirty Frag sean explotables en su entorno. Para seguir el estado de vulnerabilidades y actualizaciones confíe en fuentes centralizadas como el NVD y el árbol oficial del kernel: NVD — National Vulnerability Database y Kernel.org.