Soporte técnico
Documentación
Inicio de sesión
Contáctenos
Ir directamente al resumen generado por IA de esta entrada del blog 
¿Buscas medidas de mitigación? Ve directamente a ↓
La versión resumida
- ¿Qué? Una cadena de escalada de privilegios locales en Linux denominada Dirty Frag, que combina CVE-2026-43284 (escritura en la caché de páginas xfrm-ESP) y CVE-2026-43500 (escritura en la caché de páginas de RxRPC).
- Repercusión: Los exploits públicos de prueba de concepto demuestran una escalada fiable de privilegios de root desde una cuenta local sin privilegios en kernels vulnerables.
- Estado: Están circulando exploits públicos que funcionan. El embargo se rompió antes de que se completara la aplicación coordinada de parches.
- Gravedad: Vector de ataque local, complejidad baja, sin interacción del usuario, explotación determinista. CVSS: 7,8 (provisional)
- Haz lo siguiente ahora mismo:protegeinmediatamente los núcleos afectados. La aplicación de parches sin necesidad de reiniciar permite mitigar la vulnerabilidad «Dirty Frag» sin tener que esperar a las ventanas de mantenimiento ni a los reinicios. De lo contrario, implementa los núcleos parcheados lo antes posible. Si ninguna de estas opciones está disponible de inmediato, desactiva temporalmente las rutas ESP y RxRPC vulnerables que se indican a continuación.
¿Me afecta esto?
Es probable que te veas afectado si utilizas un kernel reciente derivado de la rama principal en cualquiera de los siguientes sistemas:
- Ubuntu (versiones LTS y actuales)
- Red Hat Enterprise Linux, AlmaLinux, Rocky Linux, CentOS Stream
- Fedora
- openSUSE Tumbleweed
- La mayoría de las versiones derivadas, incluidas las variantes de CloudLinux
Comprobación rápida de los módulos expuestos:
lsmod | grep -E '^(esp4|esp6|rxrpc)'
Si alguno de estos se carga —o puede ser cargado automáticamente bajo demanda por un usuario sin privilegios—, debes considerar que el servidor está expuesto hasta que se aplique el parche.
Eres no estás automáticamente a salvo solo por haberlo solicitado antes Copiar Fallo . Bloqueo algif_aead no detiene Dirty Frag.
¿Qué es Dirty Frag?
Dirty Frag es una cadena de escalada de privilegios locales (LPE) del núcleo que aprovecha dos rutas de descifrado en el propio sistema de la pila de red de Linux:
- xfrm-ESP (esp4, esp6), utilizado por IPsec
- RxRPC (rxrpc), utilizado por AFS y el tráfico RPC relacionado
Pertenece a la misma familia de errores que «Dirty Pipe» y «Copy Fail»: una rutina del núcleo escribe datos en una página de la que no es propietaria exclusiva, lo que acaba sobrescribiendo el contenido de una entrada de la caché de páginas que respalda un archivo en el disco.
La cadena fue revelada por el investigador Hyunwoo Kim. «Copy Fail 2: Electric Boogaloo» es la parte xfrm-ESP de Dirty Frag (CVE-2026-43284), obtenida mediante ingeniería inversa a partir de la confirmación pública de la corrección; no se trata de un CVE independiente ni de la cadena completa.
Cómo funciona realmente la vulnerabilidad
La caché de páginas de Linux almacena copias en memoria del contenido de los archivos, de modo que las lecturas repetidas no tengan que recurrir al disco. Cuando cat /etc/passwd, el núcleo casi siempre te proporciona bytes de una página almacenada en caché en lugar de hacerlo desde el sistema de archivos. Esa página almacenada en caché es compartida: todos los que leen ese archivo ven la misma memoria.
Las rutas de recepción del núcleo moderno admiten descifrado sin copia . Cuando llegan datos de red cifrados —por ejemplo, un paquete IPsec encapsulado en ESP—, el núcleo puede descifrarlos directamente en una página de destino en lugar de asignar un nuevo búfer y copiarlos dos veces. Esto es rápido y, para la mayoría de los destinos, es seguro, ya que la página de destino es algo que el núcleo ha asignado para ese fin.
Se produce un «Dirty Frag» cuando la página de destino no de propiedad privada. Mediante un uso cuidadoso de splice(2) o sendfile(2) , un proceso sin privilegios puede hacer que la ruta de recepción ESP o RxRPC del núcleo descifre los datos entrantes directamente en una página que se encuentra actualmente en la caché de páginas, incluidas las páginas que respaldan archivos confidenciales como /etc/passwd o /usr/bin/su.
Los bytes descifrados están bajo el control del atacante (el atacante eligió el texto en claro antes de cifrarlo y enviarlo). Dado que el núcleo no utiliza COW ni aísla de ningún otro modo la página de destino, la escritura se realiza en la copia compartida de la caché de páginas. Las lecturas posteriores del archivo —incluidas las realizadas por login, sudoo su – devuelven el contenido modificado.
El archivo en el disco no ha sufrido cambios. Sin embargo, es posible que en lecturas posteriores se utilice la versión modificada almacenada en la caché en lugar del contenido original del sistema de archivos.
Se encadenan dos rutas para garantizar la cobertura de la distribución:
- El ruta ESP requiere la creación de un espacio de nombres de usuario sin privilegios, lo que Ubuntu bloquea mediante AppArmor, pero la mayoría de las demás distribuciones permiten.
- La ruta RxRPC requiere que se cargue el módulo rxrpc.ko, que la mayoría de las distribuciones no incluyen de forma predeterminada, pero Ubuntu sí. El bloque de espacio de nombres de Ubuntu está cubierto por RxRPC; el rxrpc que falta en el resto está cubierto por ESP.
En conjunto, abarcan las configuraciones de endurecimiento más habituales.
Lo que hace que este fallo sea especialmente peligroso en la práctica:
- Determinista: Sin ventana de carrera, sin primitivas sensibles al tiempo.
- Sin avisar en caso de fallo: Los intentos fallidos no suelen provocar pánico en el núcleo.
- Alta tasa de éxito: Tan fiable que la prueba de concepto pública funciona a la primera.
- Rápida conversión en arma: Las cadenas de exploits públicas aparecieron antes de que se completara la aplicación coordinada de parches, lo que redujo drásticamente el tiempo de respuesta de los defensores.
Mitigación
La mejor forma de solucionar el problema es proteger inmediatamente el núcleo en ejecución. Existen tres formas prácticas de reducir la vulnerabilidad, que se enumeran a continuación por orden de rapidez e impacto operativo.
1. Aplicación de parches sin necesidad de reiniciar (la opción más rápida, sin interrupciones del servicio)
Los parches sin reinicio de KernelCare se están implementando para las familias de kernels empresariales afectadas, lo que permite proteger los kernels vulnerables en ejecución sin tener que esperar a las ventanas de mantenimiento de emergencia ni a los reinicios coordinados.
Para las organizaciones que gestionan infraestructuras en las que el tiempo de actividad es fundamental, esto reduce de inmediato el tiempo de resolución de incidencias, mientras que las actualizaciones estándar del núcleo del proveedor y los ciclos de reinicio se ponen al día.
A medida que se publiquen nuevas versiones de los paquetes del núcleo en las fases posteriores del proceso, es posible que la detección de escáneres y la información sobre las versiones de los proveedores se retrasen temporalmente con respecto al estado del núcleo en ejecución protegido.
| ¿Aún no es cliente de KernelCare? Las tarifas para nuevos clientes tienen un descuento hasta finales de junio. Más información sobre KernelCare aquí. |
2. Instala un núcleo parcheado y reinicia el sistema
El procedimiento estándar de corrección consiste en instalar los paquetes del núcleo parcheados proporcionados por el proveedor y reiniciar los sistemas afectados tan pronto como sea operativamente posible.
Da prioridad a los sistemas en los que se puede ejecutar código parcialmente fiable, incluidos los nodos de Kubernetes, los ejecutores de CI/CD, los entornos de alojamiento compartido, la infraestructura de desarrollo y las cargas de trabajo multitenant.
3. Medidas de mitigación manuales temporales (si hay que esperar para aplicar el parche)
Si no se dispone ni de parches sin reinicio ni de ventanas de reinicio inmediato, las rutas ESP y RxRPC vulnerables pueden desactivarse temporalmente mediante el bloqueo de módulos.
Lee esto primero
Si bloqueas esp4 y esp6, se interrumpirá el funcionamiento de IPsec. Si gestionas o enrutas tráfico IPsec —como strongSwan, Libreswan, VPN de sitio a sitio o clientes «road-warrior»—, aplicar esta configuración en los servidores de producción provocará la desconexión de esos túneles.
Antes de proceder a una implementación generalizada, comprueba que los módulos no estén en uso.
ip xfrm policy list 2>/dev/null | head
ss -tunap | grep -i rxrpc
Si la salida no está vacía, ten en cuenta las consecuencias antes de continuar.
Bloquea los módulos vulnerables
sudo sh -c "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"
Si se sospecha que se ha producido una filtración
Vacía la caché de páginas para que los archivos binarios almacenados en caché que se hayan modificado se eliminen y se vuelvan a leer del disco en el siguiente acceso:
sudo sh -c 'echo 3 > /proc/sys/vm/drop_caches'
Considera esto como un paso de análisis forense, no como una solución. Si un atacante ya ha obtenido privilegios de root mediante Dirty Frag, la purga de la caché de páginas no elimina nada de lo que haya hecho tras la escalada de privilegios.
Detección
En la actualidad no existe ningún método de detección a posteriori ampliamente aceptado o fiable para confirmar que la explotación de «Dirty Frag» ha tenido éxito. Los archivos del disco permanecen intactos y el ataque no deja un patrón de llamadas al sistema tan característico como el de «Dirty Pipe». Dicho esto, hay algunas señales que vale la pena buscar:
- Carga inesperada de esp4, esp6o rxrpc en hosts que no tienen nada que ver con IPsec o AFS. Regla de Auditd:
-w /sbin/modprobe -p x -k module_load
- Creación de nuevos espacios de nombres de red por parte de usuarios sin privilegios en sistemas en los que esto no forma parte de la carga de trabajo habitual. Seguimiento a través de unshare o eBPF.
- Ejecución con privilegios de setuid por parte de cuentas que nunca antes han ejecutado su o sudo, especialmente poco después de una actividad intensa con splice/sendfile.
- Clientes de Imunify360: se han añadido a la lista de bloqueados indicadores relacionados con el script de implementación del PoC público.
Se trata de pautas, no de garantías. Se debe considerar que cualquier servidor en el que un usuario local no de confianza haya tenido acceso al shell durante el periodo de exposición está potencialmente comprometido.
Lista de verificación de medidas correctoras priorizadas
- Parche: Aplique un parche que no requiera reinicio o implemente un kernel parcheado de inmediato. Los usuarios de KernelCare pueden proteger los kernels en ejecución compatibles sin necesidad de reiniciar, mientras se completan las ventanas de mantenimiento estándar. De lo contrario, instale los kernels parcheados por el proveedor y reinicie los sistemas afectados lo antes posible.
- Si no puede aplicar el parche de inmediato, aplique la medida de mitigación de bloqueo de módulos indicada anteriormente, tras confirmar que no depende de IPsec ni de RxRPC.
- Auditar el acceso local: Revisar quién tiene actualmente acceso a la línea de comandos en servidores compartidos, ejecutores de CI/CD, servidores de compilación y sistemas multitenant. Revocar lo que no sea necesario durante ese periodo.
- Búsqueda: Ejecuta las consultas de detección anteriores en la ventana de exposición.
- Reinicia después de aplicar el parche: Esto borrará cualquier página almacenada en caché que pueda haber sido modificada, junto con el núcleo antiguo.
¿Por qué los errores como «Dirty Frag» aparecen cada vez más rápido?
Dirty Frag también refleja una tendencia generalizada en el sector: la auditoría asistida por IA está acelerando la detección de fallos profundos y persistentes en las rutas de código críticas para el rendimiento.
En una publicación reciente, Igor Seletskiy, director ejecutivo de TuxCare, señaló que los modernos análisis asistidos por IA están reduciendo drásticamente el tiempo necesario para detectar vulnerabilidades sutiles en el núcleo y la infraestructura que antes pasaban desapercibidas tras años de revisión.
«Dirty Frag» encaja perfectamente en ese patrón: una vulnerabilidad relacionada con la propiedad de la caché de páginas oculta en las rutas de red de alto rendimiento, que ahora se ha convertido en un método fiable para la escalada de privilegios, con código de explotación ya disponible públicamente.
Referencias
CVE-2026-43284 (xfrm-ESP: escritura en la caché de páginas) — Entrada en la NVD: https://nvd.nist.gov/vuln/detail/CVE-2026-43284
CVE-2026-43500 (Escritura en la caché de páginas de RxRPC) — Entrada en la NVD: https://nvd.nist.gov/vuln/detail/CVE-2026-43500
- Nota: la entrada RxRPC está reservada para el seguimiento, a la espera de que se publique la entrada NVD, por lo que es posible que la página aparezca como «RESERVADA» hasta que se complete.
Artículo original del investigador — Hyunwoo Kim (@v4bel):
- Sitio alojado: https://dirtyfrag.io
- Descripción técnica completa en GitHub: https://github.com/V4bel/dirtyfrag/blob/master/assets/write-up.md
- Repositorio de PoC / README: https://github.com/V4bel/dirtyfrag
- Correo electrónico de notificación de seguridad de OSS (7 de mayo de 2026): https://www.openwall.com/lists/oss-security/2026/05/07/8
Serie de parches del núcleo en fase inicial (lore.kernel.org):
- Hilo sobre el parche RxRPC (mencionado en el aviso de AlmaLinux): https://lore.kernel.org/all/afKV2zGR6rrelPC7@v4bel/
- En cuanto a la corrección de ESP fusionada, la referencia canónica de la confirmación es la línea principal f4c50a4034e6: https://git.kernel.org/pub/scm/linux/kernel/git/netdev/net.git/commit/?id=f4c50a4034e62ab75f1d5cdd191dd5f9c77fdff4
Aviso de AlmaLinux: https://almalinux.org/blog/2026-05-07-dirty-frag/
