Fragnesia (CVE-2026-46300): una nueva vulnerabilidad de ejecución local (LPE) en el núcleo de Linux perteneciente a la familia Dirty Frag

La versión resumida

Qué: Una vulnerabilidad en el manejo de XFRM ESP-in-TCP del núcleo de Linux permite a un usuario local sin privilegios provocar modificaciones controladas en páginas almacenadas en caché que pertenecen a archivos de solo lectura, incluidos los binarios setuid.

Impacto: Escalada de privilegios locales a root mediante la modificación de la caché de páginas. El archivo en el disco permanece intacto, mientras que se altera la copia almacenada en la memoria.

Sistemas afectados: Sistemas que ejecutan las rutas de código skbuff afectadas, incluidos los núcleos que ya han recibido la corrección de Dirty Frag. La prueba de concepto pública requiere CONFIG_INET_ESPINTCP para acceder al fallo, por lo que los núcleos compilados sin esta opción bloquean este exploit; sin embargo, es posible acceder al defecto subyacente de skbuff a través de otras rutas. Las distribuciones que restringen los espacios de nombres de usuarios sin privilegios de forma predeterminada (como la configuración de AppArmor de Ubuntu) bloquean parcialmente la prueba de concepto pública.

Estado del exploit: PoC público publicado en GitHub inmediatamente después de la divulgación.

CVE ID: CVE-2026-46300

Medidas de mitigación: Desactive los módulos ESP vulnerables o aplique los parches del proveedor o los parches de seguridad en tiempo real tan pronto como estén disponibles.

Estado de la cobertura de KernelCare (actualizado el 18 de mayo de 2026, 13:00 UTC): Hay parches sin reinicio disponibles en los canales main + ePortal para AlmaLinux ELS/FIPS, Debian 11, Debian 12, la familia EL8, Rocky Linux 10, Oracle Linux 8, Oracle Linux 8 UEK 7, Oracle Linux 9, Oracle Linux 9 UEK 7, Ubuntu 22.04 (Jammy) y Ubuntu 24.04 (Noble).

kcarectl --update # pulls the patch if your kernel is in scope
kcarectl --patch-info | grep cve-2026-46300

Estado de la divulgación: Los detalles técnicos, la orientación sobre las versiones afectadas y las recomendaciones de mitigación pueden evolucionar a medida que los proveedores publiquen avisos y los mantenedores del núcleo de niveles posteriores completen las adaptaciones.

Hace cinco días, Linux publicó parches para «Dirty Frag». Hoy, los administradores de seguridad se enfrentan a otra vulnerabilidad relacionada con este tema.

Fragnesia (CVE-2026-46300) es una vulnerabilidad de escalada de privilegios locales recientemente revelada que afecta al subsistema XFRM ESP-in-TCP del núcleo de Linux. William Bowling, en colaboración con el equipo de V12 Security, la ha dado a conocer hoy, junto con una prueba de concepto funcional que sobrescribe /usr/bin/su a través de la caché de páginas y permite obtener acceso de root.

La información se hizo pública en GitHub y X inmediatamente después de que apareciera el parche en la lista de correo de netdev, sin ningún periodo de embargo. En el momento de la publicación, no se ha asignado ningún CVE, y la corrección candidata del desarrollador original se encuentra en netdev a la espera de revisión y fusión.

Lo que hace que Fragnesia sea digna de mención no es solo el exploit en sí, sino el momento en que se produjo y su origen. El parche de corrección propuesto (enviado por Bowling) cita explícitamente la corrección de Dirty Frag (f4c50a4034e6) como una de las dos confirmaciones que «corrige», lo que significa que la corrección original de Dirty Frag dejó al descubierto un error que antes estaba latente de una forma que lo hizo prácticamente explotable. Según el informe de Wiz, Hyunwoo Kim (el informante original de Dirty Frag) también ha reconocido que Fragnesia surgió como un efecto secundario no deseado de los parches de Dirty Frag.

El panorama general es preocupante: los responsables de la seguridad se ven obligados a parchear la misma vulnerabilidad dos veces en menos de una semana, mientras que los creadores de exploits se adaptan casi tan rápido como se publican las correcciones.

Por qué es importante la fragnesia

Fragnesia no es una clase de fallo totalmente independiente de Dirty Frag. Se trata de otra vía de explotación a través de la misma superficie de ataque ESP/XFRM, y la corrección original de Dirty Frag proporcionada por el desarrollador original no la detiene por completo.

El problema técnico se encuentra en skb_try_coalesce(). Cuando esa función une fragmentos paginados de un sk_buff a otro, actualmente descarta el SKBFL_SHARED_FRAG , incluso cuando el búfer resultante sigue conteniendo fragmentos de propiedad externa o respaldados por la caché de páginas. Esto rompe la invariante en la que se basa el manejo de entradas de ESP, concretamente la función skb_has_shared_frag() que decide si un skb no lineal no clonado puede omitir skb_cow_data(). Si se omite la copia en escritura, se obtiene un descifrado in situ directamente en la página compartida.

En otras palabras, la solución para el problema de «Dirty Frag» (f4c50a4034e6) añadió código que confía en que el marcador de fragmentos compartidos sea preciso. El marcador no es preciso. El parche candidato de Fragnesia incluye dos correcciones: : una para la confirmación de Dirty Frag y otra para una confirmación mucho más antigua de 2013 (cef401de7be8), lo que indica que el error de coalescencia subyacente existe desde hace años. La corrección de Dirty Frag simplemente lo hizo explotable de una manera útil.

En la práctica, el exploit consigue el mismo resultado que ya preocupaba a los defensores la semana pasada: la modificación de la caché de página de binarios con privilegios sin tocar el archivo subyacente en el disco.

Si ya has implementado la medida de mitigación «Dirty Frag» que desactivó esp4, esp6y rxrpc, ya estás protegido contra el PoC público de Fragnesia. Si solo has aplicado la corrección inicial de upstream, no lo estás.

Esa distinción es importante desde el punto de vista operativo, ya que refuerza una tendencia que los defensores observan cada vez con mayor frecuencia en la explotación moderna del núcleo: las correcciones de errores complejos relacionados con la gestión de la memoria se están convirtiendo, a su vez, en objeto de investigaciones destinadas a eludirlas rápidamente.

Cómo funciona la vulnerabilidad

A grandes rasgos, el exploit funciona así:

1. El atacante crea un nuevo usuario y un espacio de nombres de red mediante unshare(CLONE_NEWUSER | CLONE_NEWNET) para obtener CAP_NET_ADMIN dentro del espacio de nombres aislado.
2. Una asociación de seguridad ESP sobre TCP en modo de transporte se establece mediante NETLINK_XFRM utilizando AES-128-GCM con una clave conocida.
3. El exploit prepara una tabla de consulta de secuencias de teclas de 256 entradas utilizando interfaces de cifrado AF_ALG , asignando cada valor de byte posible a un nonce correspondiente.
4. Las páginas respaldadas por archivos se colocan en cola en un flujo TCP mediante splice().
5. El socket se cambia a modo espintcp ULP una vez que las páginas ya están en la cola.
6. Porque skb_try_coalesce() ya ha eliminado previamente el marcador de fragmento compartido, el núcleo procede a realizar el descifrado AES-GCM in situ directamente en las páginas compartidas almacenadas en caché.
7. El byte del flujo de claves seleccionado se aplica mediante una operación XOR a la página de destino, lo que da lugar a una escritura controlada de un solo byte. Repite este proceso para cada byte hasta que se haya escrito toda la carga útil.

El PoC público sobrescribe la copia almacenada en caché de

/usr/bin/su con una pequeña carga útil ELF independiente de la posición que ejecuta:

setresuid(0,0,0);

execve("/bin/sh");

Este exploit destaca porque no se basa en una ventana de carrera muy limitada que deba completarse con éxito exactamente una vez. El atacante ejecuta repetidamente la primitiva de escritura hasta que los bytes deseados se escriben correctamente, lo que hace que el proceso sea mucho más determinista que muchos exploits históricos de condiciones de carrera del núcleo.

La página almacenada en caché modificada puede permanecer hasta que se elimine o se reinicie el sistema, lo que significa que las ejecuciones repetidas del binario en cuestión pueden seguir proporcionando acceso de root aunque el hash del archivo en el disco no cambie.

¿Quiénes son los más vulnerables?

Los entornos de mayor riesgo son aquellos sistemas que combinan:

• ejecución de código local no confiable,
• espacios de nombres sin privilegios habilitados,
• cargas de trabajo multitenant,
• y compatibilidad activa con el núcleo XFRM/ESP.

Por eso es especialmente importante dar prioridad a los siguientes entornos:

• Nodos de trabajo de Kubernetes
• Ejecutores de CI/CD compartidos
• Plataformas de alojamiento compartido
• Servidores de Bastion y Jump
• Estaciones de trabajo para desarrolladores
• Infraestructura de contenedores multitenant

En el caso de estos sistemas, una vulnerabilidad de escalada de privilegios «local» ya casi nunca se limita al ámbito local. Un contenedor comprometido, una tarea de CI maliciosa, una clave SSH robada o una ejecución remota de código (RCE) en una aplicación pueden convertirse en puntos de acceso para comprometer por completo el host.

Aplicación de parches sin reinicio en Fragnesia con KernelCare

En el caso de los sistemas mencionados anteriormente —nodos de Kubernetes multitenant, ejecutores de CI compartidos, hosts bastión—, la cuestión práctica es la rapidez con la que se puede implementar realmente una corrección. La herramienta de aplicación de parches sin reinicio de TuxCare, KernelCare, lanzó parches sin reinicio para la familia de kernels EL8 en las 24 horas siguientes a la divulgación de Dirty Frag la semana pasada, antes de las erratas correspondientes de los proveedores. EL9, Ubuntu, Debian y Proxmox VE siguieron la misma línea de lanzamiento. Ese es el punto de referencia de lo que significa «rápido» en esta clase de gravedad.

En el caso de Fragnesia, el proceso va a ser un poco más complicado. La corrección en el código fuente sigue en netdev a la espera de revisión, lo que significa que el primer parche de KernelCare se compilará sobre una versión candidata. Si la versión fusionada por el mantenedor acaba siendo diferente, es probable que haya que volver a compilar. Y dado que ese parche candidato lleva una etiqueta «Fixes:» que apunta a una confirmación de 2013, es probable que se realicen más auditorías de skb_try_coalesce(): es posible que el primer parche sin reinicio que se publique no sea el último para esta superficie de ataque.

Esa periodicidad es precisamente la que se da en la aplicación de parches sin reinicio. Dos parches en cinco días para el mismo subsistema, ambos con PoC públicos antes de que las erratas del proveedor pudieran ponerse al día, y un tercero que es muy probable que llegue. La alternativa —que se explica en la siguiente sección— consiste en incluir módulos en la lista negra, aplicar restricciones de espacio de nombres y realizar un reinicio progresivo no programado una vez que tu distribución lance un paquete del kernel. Nodos de Kubernetes agotados dos veces en una semana. Ejecutores de CI reiniciados en mitad de la compilación. Conmutaciones por error de bastión que nadie programó.

Una advertencia sincera: algunos escáneres de vulnerabilidades seguirán señalando la versión del paquete del núcleo sin parchear tras la aplicación de parches en tiempo real, ya que la lógica de detección del escáner va por detrás del estado real del núcleo en ejecución. El núcleo está protegido. Es posible que tu panel de control no refleje esta información durante uno o dos días. Redacta la explicación del ticket teniendo esto en cuenta.

Si aún no utilizas KernelCare y esta semana se te ha desajustado el calendario de actualizaciones, es un buen momento para echarle un vistazo. Los precios para nuevos clientes tienen descuento hasta finales de junio. Consigue KernelCare → 

Mitigación

Medidas de mitigación inmediatas

La misma lista negra de módulos que se utiliza para Dirty Frag también bloquea el exploit público de Fragnesia:

sudo sh -c "printf 'install esp4 /bin/false\ninstall esp6 /bin/false\ninstall rxrpc /bin/false\n' > /etc/modprobe.d/fragnesia.conf; rmmod esp4 esp6 rxrpc 2>/dev/null; true"

Si /etc/modprobe.d/dirtyfrag.conf ya existe debido a medidas de mitigación anteriores, puede dejarlo donde está.

Aviso operativo

Desactivar esp4 y esp6 interrumpe el funcionamiento de las VPN basadas en IPsec y ESP, incluidas las implementaciones que utilizan strongSwan o Libreswan. Las implementaciones de WireGuard no se ven afectadas.

rxrpc está asociado a los clientes AFS y, por lo general, es seguro desactivarlo en servidores típicos.

Comprueba las dependencias operativas antes de implementar estas medidas correctivas a gran escala.

Restringir los espacios de nombres de los usuarios sin privilegios

Los sistemas Ubuntu se resisten parcialmente a la prueba de concepto pública porque AppArmor restringe de forma predeterminada los espacios de nombres de los usuarios sin privilegios. La propia prueba de concepto indica a los usuarios que desactiven:

kernel.apparmor_restrict_unprivileged_userns=0

antes de su explotación.

Los sistemas de la familia RHEL pueden ofrecer un nivel de protección similar mediante:

echo "user.max_user_namespaces=0" > /etc/sysctl.d/fragnesia.conf

sysctl --system

Esto solo supone una solución parcial. Además, provoca fallos en los contenedores sin privilegios de root, Flatpak, los navegadores en entornos aislados y otras herramientas que dependen de los espacios de nombres.

Vaciar la caché de páginas envenenadas

Dado que la vulnerabilidad solo modifica las páginas almacenadas en la caché, los sistemas de los que se sospeche que han sido comprometidos deben vaciar el contenido de la caché de páginas tras aplicar las medidas de mitigación:

sudo sh -c 'echo 3 > /proc/sys/vm/drop_caches'

Esto elimina la persistencia inmediata de la caché de la página, pero no garantiza que el atacante no haya logrado establecer una persistencia más duradera posteriormente. Cualquier explotación que tenga éxito debe considerarse como una compromisión total del host.

Aplicar las correcciones del proveedor

Aplica las actualizaciones del núcleo proporcionadas por el proveedor o los parches en tiempo real validados tan pronto como estén disponibles para tu distribución.

En el momento de la publicación, el parche de seguimiento propuesto por William Bowling:

[PARCHE net] net: skbuff: conservar el marcador de fragmentos compartidos durante la fusión

está en la lista de correo de netdev a la espera de ser revisado. El parche es breve: dos líneas en skb_try_coalesce() que conservan el SKBFL_SHARED_FRAG al transferir descriptores de fragmentos. Es probable que los mantenedores incorporen una versión de esto rápidamente, pero las adaptaciones posteriores en las distintas distribuciones tardarán más tiempo.

Esto es importante porque es posible que los responsables de la seguridad tengan que abordar esto como un ciclo de parches en constante evolución, en lugar de como una única acción correctiva. Las dos correcciones: en el parche sugieren que se justifica un trabajo de auditoría más amplio en la ruta de fusión de skb.

Guía de detección

Las herramientas tradicionales de verificación de la integridad de los archivos no son adecuadas para este tipo de ataques:

• Los hash almacenados en el disco siguen siendo correctos
• Es posible que AIDE y Tripwire no detecten ninguna modificación
• El cambio malicioso desaparece tras el vaciado de la caché o al reiniciar el sistema

La detección basada en el comportamiento es mucho más prometedora.

Entre las posibles señales se incluyen:

• desasignar(CLONE_NEWUSER | CLONE_NEWNET) de procesos inesperados
• NETLINK_XFRM actividad procedente de cargas de trabajo no relacionadas con la funcionalidad VPN
• Inusualmente intenso AF_ALG , especialmente en bucles muy cortos
• splice() Operaciones de unión de archivos normales en sockets TCP seguidas de cambios en la ULP en el mismo socket

Ninguna de estas acciones es intrínsecamente maliciosa por sí sola, pero su combinación resulta lo suficientemente sospechosa como para justificar la aplicación de reglas de detección en tiempo de ejecución mediante herramientas eBPF, Falco, Tetragon o plataformas EDR para Linux.

El panorama general

Las investigaciones recientes sobre la escalada de privilegios en Linux han señalado repetidamente la corrupción de la caché de páginas, la propiedad de la memoria compartida y los errores de procesamiento in situ, entre los que se incluyen:

• Dirty Pipe (2022)
• Error al copiar (2026)
• Dirty Frag (2026)
• Fragnesia (2026)

Tres de ellos salieron a la luz en tan solo unas semanas.

El patrón común resulta cada vez más evidente: las rutas del núcleo altamente optimizadas que implican la gestión de la propiedad de la memoria compartida, el manejo de páginas y el procesamiento in situ siguen generando primitivas de escritura peligrosas cuando fallan las suposiciones en casos extremos.

splice(), la fusión de skb, el procesamiento de ESP y las interacciones con la caché de páginas son todos subsistemas orientados al rendimiento. Los atacantes están demostrando cada vez más que esas optimizaciones pueden convertirse en vías fiables para la escalada de privilegios cuando falla la semántica de propiedad.

Fragnesia también destaca por la rapidez con la que apareció tras la implementación de las correcciones originales para Dirty Frag. V12 Security atribuye parte del proceso de detección a las herramientas de seguridad asistidas por IA de tipo «agente», y, independientemente del peso que se le dé a esa afirmación, el ritmo de iteración de los exploits se está acelerando. El hecho de que la corrección propuesta incluya un Etiqueta de correcciones: que apunta a una confirmación de 2013 también sugiere que la clase de errores no se ha agotado: probablemente haya más violaciones de invariantes en la misma ruta de código esperando a ser descubiertas.

Los defensores deben dar por hecho que esta clase de insectos aún no ha terminado de evolucionar.

Resumen

Nombre del artículo

Fragnesia (CVE-2026-46300): nueva vulnerabilidad de ejecución de código local en Linux que elude el parche «Dirty Frag»

Descripción

Fragnesia (CVE-2026-46300) es una nueva vulnerabilidad de ejecución local (LPE) del núcleo de Linux que amplía la familia Dirty Frag (CVE-2026-43284, CVE-2026-43500).

Autor

Tim Walker

Nombre del editor

TuxCare

Logotipo de la editorial