DirtyClone: la vulnerabilidad del kernel Linux que permite escalar privilegios sin tocar el disco

Un nuevo exploit de escalada de privilegios llamado DirtyClone (CVE-2026-43503, CVSS 8.8) vuelve a poner en evidencia una misma debilidad arquitectural en el subsistema de red del kernel Linux: la optimización de cero-copia que permite tratar páginas de archivo como datos de paquetes puede transformarse en una primitiva de escritura si en algún punto del código se pierde una bandera de seguridad. JFrog Security Research hizo pública una demostración funcional el 25 de junio que muestra cómo un atacante local puede corromper memoria respaldada por archivo y, sin tocar el disco, conseguir root sustituyendo bytes de un binario privilegiado en memoria (por ejemplo /usr/bin/su) y provocando su ejecución posterior con privilegios elevados.

El vector concreto de DirtyClone explota que dos funciones auxiliares que intervienen cuando el kernel clona un paquete de red dejan de propagar el bit que marca fragmentos compartidos con el sistema de ficheros. El exploit encadena la colocación de páginas de un binario privilegiado dentro de un skb (socket buffer), la clonación de ese skb y su paso por un túnel IPsec controlado por el atacante: durante la descompresión/desencriptado en la ruta de recepción el kernel sobrescribe la memoria mapeada con datos controlados por el atacante. El archivo en disco no se modifica, las herramientas de integridad de ficheros no detectan nada y un reinicio restaura la imagen en disco; en otras palabras, la modificación es temporal pero suficiente porque el atacante ya tiene root antes de que alguien lo note.

Es importante entender dónde aplican las limitaciones prácticas: la explotación requiere la capacidad CAP_NET_ADMIN para configurar el túnel loopback IPsec. En distribuciones que permiten creación de user namespaces sin privilegios (por ejemplo Debian y Fedora con configuración por defecto) un usuario local puede obtener CAP_NET_ADMIN dentro de un namespace y así montar la ruta de explotación. Ubuntu 24.04 y posteriores han endurecido la creación de namespaces mediante AppArmor, lo que bloquea la vía de explotación por defecto en esa plataforma.

DirtyClone no es un caso aislado: es la cuarta variante en semanas que aprovecha el mismo fallo de contrato en el manejo de fragmentos skb. Copy Fail, DirtyFrag y Fragnesia fueron variantes anteriores que encontraron otras funciones donde no se respetaba la misma regla: cada camino que mueva descriptores de fragmento debe preservar el bit shared-frag. El parche combinado que selló múltiples puntos débiles se integró en mainline el 21 de mayo (commit 48f6a5356a33) y se ha ido retroportando a ramas estables y LTS; sin embargo, la presencia reiterada de variantes indica que la superficie sigue siendo amplia y requiere auditoría exhaustiva.

Acciones inmediatas y prácticas que deberían tomar los administradores: actualizar el kernel cuanto antes a una versión con el parche aplicado (la corrección está en Linux v7.1-rc5 y en backports estables/LTS). Después de parchear, reinicie los sistemas afectados: dado que la explotación altera solo la memoria en vivo, un reinicio limpia las modificaciones temporales y cierra el vector activo de una intrusión reciente. Consulte el registro oficial del kernel para el commit de la corrección: commit 48f6a5356a33 y el detalle CVE en la base NVD: CVE-2026-43503.

Si no puede desplegar el parche de inmediato, hay dos mitigaciones temporales que reducen la superficie de ataque: desactivar la creación de user namespaces sin privilegios (en Debian y Ubuntu puede hacerse con kernel.unprivileged_userns_clone=0 mediante sysctl o /etc/sysctl.conf) y/o bloquear los módulos del kernel implicados (esp4, esp6 y rxrpc) añadiéndolos a la lista negra de modprobe. Ambas medidas tienen impacto funcional —bloquear esp* deshabilita IPsec y el blacklisting solo funciona si esos componentes son módulos y no están compilados en el kernel— así que deben aplicarse con conocimiento del entorno. Estas mitigaciones no sustituyen la actualización completa del kernel.

Los entornos más expuestos son aquellos multi-tenant o que permiten a usuarios no confiables crear namespaces y manipular la red: servidores públicos, runners de CI compartidos, hosts de contenedores y clústeres Kubernetes con políticas laxas. En estos escenarios conviene aplicar controles adicionales: minimizar las capacidades concedidas a contenedores (no conceder CAP_NET_ADMIN salvo necesidad, usar perfiles de seccomp/SELinux/AppArmor), restringir quién puede crear namespaces y revisar la configuración del runtime de contenedores para impedir escape por capacidades de red.

Desde una perspectiva de defensa y gestión del riesgo, hay dos mensajes claros. Primero, la clase de fallos que provoca DirtyClone es una vulnerabilidad de contrato entre componentes del kernel: la solución no es solo parchear funciones concretas sino auditar y reforzar la invariancia en todo el código que mueve fragmentos skb. Segundo, para operadores la detección es difícil porque los cambios no tocan el disco ni dejan rastro en las integridades de archivos; por eso, la respuesta ante la sospecha de compromiso debe incluir actualización + reinicio y, en casos razonables, reconstrucción desde imágenes confiables. Mantenga procesos de parcheo acelerado para kernels y revise políticas de aislamiento para usuarios y cargas de trabajo.

Finalmente, los equipos de seguridad y de plataforma deberían monitorizar los avisos de su distribución y aplicar los parches y backports que publiquen los vendors; además, valorar controles preventivos a nivel de política de contenedores y capacidad de detección de actividad anómala en la red interna. La recurrencia de variantes en el mismo «family bug» es una llamada a reforzar tanto el proceso de desarrollo del kernel como las estrategias de defensa en profundidad en infraestructuras compartidas.