Cómo funciona el ataque

El problema se origina cuando el kernel clona internamente un paquete de red. Durante este proceso, dos funciones auxiliares eliminan un indicador de seguridad encargado de señalar que la memoria del paquete está compartida con un archivo almacenado en disco. La pérdida de este indicador es la causa de la vulnerabilidad.

Para explotar la falla, un atacante carga en memoria un binario privilegiado, como /usr/bin/su, enlaza sus páginas de memoria a un paquete de red y obliga al kernel a clonarlo. Posteriormente, el paquete atraviesa un túnel IPsec controlado por el atacante, donde el proceso de descifrado sobrescribe las comprobaciones de autenticación del binario con datos elegidos por el propio atacante. La siguiente vez que cualquier usuario ejecute su, el sistema concederá acceso root.

Una de las características más preocupantes del ataque es que el archivo almacenado en disco nunca se modifica. La alteración existe únicamente en la copia del archivo mantenida en memoria por el kernel, por lo que las herramientas de verificación de integridad no detectan cambios, no se generan registros de auditoría y un reinicio del sistema restaura el binario original. Sin embargo, para entonces el atacante ya habrá obtenido privilegios administrativos.

Sistemas afectados

La explotación requiere la capacidad CAP_NET_ADMIN para configurar un túnel IPsec sobre la interfaz de loopback. En distribuciones como Debian y Fedora, los espacios de nombres (user namespaces) sin privilegios están habilitados de forma predeterminada, permitiendo que un usuario local obtenga dicha capacidad dentro de un nuevo namespace.

En cambio, Ubuntu 24.04 y versiones posteriores limitan la creación de namespaces mediante AppArmor, bloqueando la vía de explotación utilizada por defecto.

Los entornos con mayor riesgo son servidores multiusuario, plataformas de integración continua (CI), hosts de contenedores y clústeres de Kubernetes donde usuarios no confiables pueden crear namespaces. JFrog confirmó el funcionamiento del exploit en sistemas Debian, Ubuntu y Fedora con configuraciones predeterminadas.

La cuarta vulnerabilidad de una misma familia

DirtyClone representa la cuarta vulnerabilidad reciente basada en el mismo mecanismo: memoria respaldada por archivos es tratada como datos de red y posteriormente modificada por operaciones que deberían haber realizado una copia.

La secuencia comenzó con Copy Fail (CVE-2026-31431) a finales de abril, seguida por DirtyFrag (CVE-2026-43284 y CVE-2026-43500) el 7 de mayo y Fragnesia (CVE-2026-46300) el 13 de mayo.

Cada parche solucionó una ruta específica del código, pero dejó otras abiertas. En el caso de DirtyClone, el exploit aprovecha principalmente la función __pskb_copy_fclone(), aunque skb_shift() también resulta afectada. La corrección definitiva amplía la protección a otras funciones encargadas de transferir fragmentos de paquetes donde podía perderse el indicador de seguridad.

Los investigadores señalan que el problema no reside en una única función defectuosa, sino en que todas las rutas que manipulan fragmentos de skb deben preservar correctamente el indicador shared-frag. Si ese requisito no se cumple en cualquiera de ellas, una optimización de rendimiento basada en redes de copia cero (zero-copy networking) puede convertirse en un mecanismo para escribir datos en memoria de forma indebida.

Actualizaciones y mitigaciones

El investigador Hyunwoo Kim, descubridor original de DirtyFrag, propuso el 16 de mayo una corrección más amplia que cubría varios puntos vulnerables. El parche fue integrado el 21 de mayo mediante el commit 48f6a5356a33, recibió el identificador CVE-2026-43503 el 23 de mayo y se incorporó a Linux v7.1-rc5 el 24 de mayo.

La principal recomendación es instalar cuanto antes las actualizaciones del kernel distribuidas por cada proveedor. El parche ya fue incorporado a las ramas estables y de soporte extendido (LTS). Ubuntu, Debian y SUSE publicaron avisos de seguridad, mientras que Red Hat mantiene un seguimiento del problema a través de Bugzilla.

Cuando la actualización inmediata no sea posible, existen dos medidas temporales para reducir el riesgo. La primera consiste en restringir la creación de user namespaces sin privilegios; en Debian y Ubuntu puede hacerse estableciendo el parámetro kernel.unprivileged_userns_clone=0. La segunda es deshabilitar los módulos del kernel esp4, esp6 y rxrpc, aunque esto inutiliza funciones como IPsec y AFS y solo resulta efectivo si dichos módulos no están integrados directamente en el kernel.

Los investigadores advierten que la familia de vulnerabilidades DirtyFrag podría seguir creciendo. Cualquier función que transfiera fragmentos de memoria sin conservar correctamente el indicador shared-frag podría convertirse en un nuevo vector de ataque y dar origen a futuras vulnerabilidades de seguridad.