El fallo de fragmentación de IPv6 que rompe el aislamiento de los contenedores en EL10

La versión resumida

¿Qué: Una vulnerabilidad de escalada de privilegios locales y de escape del contenedor en Linux, conocida como «ipv6-frag-escape». Un error aritmético en la ruta de salida de los paquetes IPv6 (__ip6_append_data()) reduce el tamaño del cabezal lineal de un búfer de socket en fraggap bytes, por lo que una copia posterior se desborda en el skb_shared_info al final de esa misma asignación. Ese desbordamiento de pila dentro del bloque es suficiente para que un proceso sin privilegios que se encuentre dentro de un contenedor se convierta en root en el host. En el momento de la publicación aún no se le ha asignado ningún CVE.

Impacto: Una prueba de concepto pública de sgkdev (github.com/sgkdev/ipv6_frag_escape) permite obtener un shell de root interactivo en los espacios de nombres iniciales y el sistema de archivos raíz del host, partiendo de un proceso sin privilegios dentro de un contenedor aislado de la red. El archivo README enumera los sistemas probados, entre los que se incluyen CentOS Stream 10 (6.12.0-242.el10) y RHEL 10 (6.12.0-228.el10). KernelCare reprodujo internamente el acceso a root del host en AlmaLinux 10.2 (6.12.0-211.7.3.el10_2) el 29 de junio de 2026 —uid=0 en los espacios de nombres de init—, en el primer intento.

Estado: Se trata de un error de la rama principal, corregido en el código fuente original en Linux 7.2-rc1 mediante una confirmación de fusión. 38becddc, que incluye la corrección para IPv6 736b380e28d0 y su homólogo IPv4 eca856950f7c. Las versiones afectadas son de la 6.6 a la 7.1. Hasta esta mañana no había versiones retrocompatibles en la distribución; pero eso ya está cambiando: AlmaLinux ha incorporado las actualizaciones de IPv4/IPv6 del proyecto original fraggap correcciones en el código fuente del paquete del núcleo a las 08:51 UTC del 30 de junio (6.12.0-211.28.2). Comprueba los repositorios de tu distribución antes de dar por hecho que aún estás a la espera de una corrección.

Gravedad: Alta para los sistemas EL10 expuestos. Vector de ataque local, baja complejidad una vez cumplidos los requisitos previos, sin interacción del usuario y con un exploit público operativo contra EL10 sin modificar. No hay puntuación CVSS porque aún no existe un CVE. Clase de fallo: desbordamiento lineal de heap/slab → uso de una página tras su liberación (use-after-free) → escalada de privilegios y escape del espacio de nombres.

Por qué es importante: Cualquier proceso sin privilegios puede acceder al disparador; así lo indica directamente la confirmación de la corrección en el código fuente: un socket UDPv6 que utiliza MSG_MORE junto con MSG_SPLICE_PAGES. No se requiere capacidad de host, solo acceso a los espacios de nombres de usuario sin privilegios dentro del contenedor. Los hosts de contenedores, el alojamiento compartido, los ejecutores de CI y los entornos Linux multitenant son precisamente los entornos en los que esto falla, ya que el exploit termina en el lado equivocado de la frontera en torno a la cual se han diseñado esas plataformas.

Haz esto ahora mismo: Aplicar un núcleo fijo o un KernelCare parche que no requiera reinicio, cuando esté disponible. Hasta entonces, la solución provisional más eficaz para EL10 es arrancar con init_on_alloc=1, lo que hace que el exploit público provoque un fallo del núcleo en lugar de un shell de root; esta ya es la configuración predeterminada en tiempo de compilación en Ubuntu y Debian, razón por la cual, en esos sistemas, el mismo fallo solo provoca un ataque de denegación de servicio (DoS). Cuando tu entorno de trabajo lo permita, desactivar los espacios de nombres de usuario sin privilegios elimina la vía de escape. Considera ambas medidas como soluciones provisionales.

La versión larga

«ipv6-frag-escape» es otro ejemplo de un fallo del núcleo de Linux que pasó de ser una «pequeña corrección aritmética» a convertirse en un «vulnerabilidad pública de nivel root» antes de que la mayoría de las organizaciones dispusieran de un CVE, una regla de escáner o un aviso del proveedor para tomar medidas al respecto.

KernelCare tuvo conocimiento de la prueba de concepto (PoC) pública el 29 de junio y, a la mañana siguiente, logró reproducir el acceso a root en el sistema en sus propias instalaciones, en un equipo con AlmaLinux 10.2 sin modificaciones; poco después, ya se estaba preparando un parche que no requería reinicio.

El repositorio se describe a sí mismo como un método fiable para escapar de contenedores y jaulas sin privilegios en CentOS y RHEL 10, aprovechando un error de fragmentación de IPv6 —ya corregido— en __ip6_append_data() que produce un desbordamiento lineal dentro de la losa hacia skb_shared_info.

Una idea clave que hay que tener presente antes de entrar en detalles: se trata de un error de la rama principal, no de una peculiaridad de EL10. Todos los kernels, desde la versión 6.6 hasta la 7.1, que no incluyan la corrección contienen el código vulnerable. EL10 es simplemente el único entorno para el que existe actualmente un exploit público y utilizado con fines maliciosos, y las vulnerabilidades de ese exploit —un EL10 uname El control, la paginación de 5 niveles y el hecho de que la opción «init-on-alloc» esté desactivada son características del arma, no del error.

Cómo funciona la vulnerabilidad

La cadena va desde una operación de escritura en un socket sin privilegios hasta un shell de root en el host:

[Unprivileged socket input]
│  UDPv6 + MSG_MORE + MSG_SPLICE_PAGES
▼
[__ip6_append_data() miscalculation]
│  linear head under-sized by fraggap bytes
▼
[Linear slab overflow]
│  writes past skb->end into skb_shared_info
▼
[Page use-after-free]
│  put_page() drops a ref on an attacker-owned page
▼
[Dirty-Pagetable reclamation]
│  freed page reused as a leaf page table → kernel R/W
▼
[Host namespace escape]
│  credentials overwritten, SELinux neutered, core_pattern hijacked
▼
[Host root shell (uid=0)]

El error de asignación. En net/ipv6/ip6_output.c, cuando __ip6_append_data() toma la rama de asignación por páginas que calcula alloclen = fragheaderlen + transhdrlen y pagedlen = datalen - transhdrlen. El problema es que datalen ya incluye fraggap – bytes transferidos desde el skb anterior que luego se copian en el cabezal lineal. Por lo tanto, al cabezal le faltan exactamente fraggap bytes mientras pagedlen se ha sobrevalorado en la misma cantidad.

El desbordamiento. La copia de seguimiento sobrescribe el contenido anterior skb->end hacia el skb_shared_info situado al final del propio objeto «head» del paquete. Un desbordamiento de pila lineal limpio, dentro del bloque.

El gatillo. Un proceso sin privilegios accede a la ruta defectuosa a través de un socket UDPv6 utilizando MSG_MORE junto con MSG_SPLICE_PAGES. El error de contabilidad se introdujo ya en la versión 6.0 con la ruta de envío «zero-copy», pero permaneció inaccesible hasta que el MSG_SPLICE_PAGES En la sección 6.6, se dejó que la ruta continuara en lugar de volver atrás. -EINVAL. Por eso 6,6 es el límite inferior.

Desbordamiento en la lectura/escritura del núcleo. La corrupción otorga el control de la única nr_frags byte en skb_shared_info. Con un puntero a la página del búfer de canal preasignado en una frags[] Desmontaje de ranuras y zócalos (skb_release_data() → put_page()) inserta una referencia en una página que el atacante aún controla, lo que convierte el desbordamiento en un uso de página tras su liberación. A continuación, la página liberada se reutiliza como tabla de páginas de último nivel —la condición «Dirty-Pagetable»—, de modo que una única página física actúa a la vez como tabla de páginas activa y como página que el atacante sigue leyendo y escribiendo a través del canal. Una PTE falsificada con autoaliasamiento amplía esto a un acceso general de lectura/escritura en el núcleo.

Escapar al host. A partir de operaciones de lectura y escritura en el núcleo, el PoC elude el KASLR utilizando la tabla de páginas fija «SMP-trampoline» de memoria baja, sobrescribe las credenciales del proceso, modifica la ruta de denegación de SELinux en memoria y secuestra core_pattern Así pues, un «usermodehelper» se ejecuta como root en los espacios de nombres iniciales del host. Ese último paso es la vía de escape.

El archivo README público documenta esta cadena, pero omite deliberadamente la infraestructura de fiabilidad —el proceso de preparación de PCP y el trabajo de caché cruzada que garantizan su funcionamiento coherente— y limita el binario distribuido a EL10 con un requisito de paginación de 5 niveles. Se trata de una prueba de concepto, no de un arma lista para usar. Sin embargo, hay dos consecuencias importantes para los defensores: una vez que se ejecuta el exploit, getenforce sigue informando Enforcing aunque se haya suavizado la aplicación de SELinux y la corrupción se produzca en la memoria del núcleo en lugar de en el disco, por lo que las herramientas de integridad de archivos no detectan nada.

Qué cambia con la corrección de Upstream

La solución consiste en unas pocas líneas, y precisamente por eso es fácil subestimar la gravedad del problema. En la ruta de asignación por páginas de IPv6, añade fraggap a alloclen y lo resta de pagedlen, por lo que el cabezal lineal tiene un tamaño suficiente para los bytes que realmente se copian en él y la parte paginada se reduce para adaptarse a ello. También elimina el ahora obsoleto MSG_SPLICE_PAGES excepción en la comprobación de copia negativa.

La ruta IPv4 en __ip_append_data() presentaba el mismo error contable y se le aplica la misma corrección (eca856950f7c). IPv6 es el caso más grave y susceptible de ser explotado; la versión correspondiente a IPv4 se ha corregido para completar la solución. Dado que ambas funciones procesan las rutas de envío paquete a paquete y no mantienen ningún estado persistente, la corrección es una opción muy viable para un parche que se pueda aplicar casi tal cual sin necesidad de reiniciar el sistema.

¿A quién afecta?

El fallo es más amplio que la vulnerabilidad explotada. La hipótesis de trabajo más segura es que cualquier núcleo comprendido entre las versiones 6.6 y 7.1 lo presenta, a menos que cuente con la corrección del desarrollador original o una adaptación de versiones posteriores. La prueba de concepto pública, por su parte, es deliberadamente limitada: se dirige a los núcleos de la familia EL10 6.12.x, requiere espacios de nombres de usuario sin privilegios, espera una paginación de 5 niveles (LA57) y depende de CONFIG_INIT_ON_ALLOC_DEFAULT_ON estar apagado.

Se ha confirmado que es vulnerable: se ha detectado acceso de root en el servidor:

• CentOS Stream 10 en la versión 6.12.0-242.el10, indicada como objetivo por el autor de la prueba de concepto.
• RHEL 10 en 6.12.0-228.el10, también mencionado por el autor de la demostración de concepto.
• AlmaLinux 10.2 en 6.12.0-211.7.3.el10_2, reproducido internamente por KernelCare el 29 de junio de 2026.

Personas que se prevé que estén expuestas: RHEL 10, CentOS Stream 10, AlmaLinux 10, Rocky Linux 10, Oracle Linux 10 y CloudLinux OS 10 que ejecutan los núcleos afectados de la familia EL10 6.12.x sin la corrección ni un parche que no requiera reinicio. Estas versiones comparten los requisitos de compilación de RHEL 10, entre los que se incluyen init_on_alloc desactivadas, así que considéralas activadas a menos que hayas confirmado lo contrario.

Existe un fallo; la técnica pública actual se limita a la denegación de servicio:

• Ubuntu 24.04 «Noble» (6.8) y Debian 13 «Trixie» (6.12.x). Las pruebas realizadas por KernelCare revelaron que CONFIG_INIT_ON_ALLOC_DEFAULT_ON=y en los núcleos enviados, lo que pone a cero el puntero «stale» implantado y provoca que la cadena termine en un fallo del núcleo en lugar de en una fuga de privilegios a nivel de root. La prueba de concepto (PoC) también tiene un límite estricto en EL10 uname y a la paginación de 5 niveles, por lo que no funciona en estos equipos tal y como se suministran.

Ese resultado, que solo provoca un denegación de servicio (DoS), es específico de la técnica actual. El archivo README indica que podría aparecer un exploit diferente, que tenga en cuenta la iniciativa «init-on-alloc», una vez que se hagan públicos la corrección y el CVE. Considera que Ubuntu y Debian están expuestos, pero que, por el momento, no se pueden explotar; no son seguros.

No se ve afectado por este desencadenante:

• Versiones de Kernel anteriores a la 6.6, en las que el MSG_SPLICE_PAGES La ruta no existe y el disparador devuelve -EINVAL.
• Kernels que incorporan la fusión 38becddc, corrección de IPv6 736b380e28d0, corrección de IPv4 eca856950f7c, o una adaptación a una versión anterior.

Una advertencia: un sistema que simplemente no cumple los supuestos del PoC —por ejemplo, la paginación de cuatro niveles— no se ha solucionado. Es inmune a este PoC concreto, pero el error del núcleo sigue estando presente en el fondo.

Actúa ya

La solución definitiva consiste en un kernel parcheado o un parche de KernelCare que no requiere reinicio. Hasta que eso se generalice, hay dos medidas prácticas que se pueden tomar.

1. Activa la opción «init-on-alloc» (recomendada en EL10). El exploit público se basa en introducir un puntero obsoleto en la memoria «slab» no inicializada. Poner a cero la memoria al asignarla impide que se produzca ese fallo. Esta opción ya está activada por defecto en Ubuntu y Debian; en EL10 suele estar desactivada.

Comprueba la configuración del núcleo, no la línea de comandos de arranque: suele ser un valor predeterminado de la compilación y no aparecerá en /proc/cmdline:

grep CONFIG_INIT_ON_ALLOC_DEFAULT_ON /boot/config-$(uname -r)   # =y means on

Para encenderlo cuando está apagado:

sudo grubby --update-kernel=ALL --args="init_on_alloc=1"
sudo reboot

El coste es una pequeña sobrecarga del asignador. El inconveniente es que hay que reiniciar el sistema para que se aplique, por lo que es más adecuado para una ventana de mantenimiento que para una respuesta de emergencia inmediata.

2. Desactivar los espacios de nombres de usuario sin privilegios. La cadena comienza en un proceso sin privilegios dentro de un contenedor y se basa en el comportamiento de los espacios de nombres sin privilegios. Al eliminar esa primitiva, se interrumpe la ruta pública, independientemente del estado del asignador.

sysctl user.max_user_namespaces             # check current value
sudo sysctl -w user.max_user_namespaces=0
echo 'user.max_user_namespaces = 0' | sudo tee /etc/sysctl.d/99-ipv6-frag-escape.conf

Esto provoca fallos en Podman y Docker sin privilegios de root, en algunos entornos de aislamiento de CI, en entornos de aislamiento al estilo Flatpak, en el comando `unshare(1)` sin privilegios y en entornos de aislamiento de navegadores. Funciona correctamente en perfiles de servidores dedicados, pero causa problemas en hosts de desarrollo y de contenedores. Prueba antes de una implementación generalizada.

El momento decisivo: Si el servidor no ejecuta contenedores sin privilegios de root y puedes reiniciarlo → configura init_on_alloc=1; reclassifica el error como un fallo del sistema, incluso si la primitiva «userns» vuelve a funcionar más tarde. Si no puedes reiniciar el sistema pero puedes prescindir de los usuarios sin privilegios → desactívalo como solución provisional sin reinicio. Si necesitas tanto contenedores sin privilegios de root como un tiempo de inactividad nulo → el parche sin reinicio o un kernel corregido es la única solución real, y deberías aislar la ejecución local no fiable hasta que se implemente una de estas soluciones.

Parche sin reinicio de KernelCare

Ambos __ip6_append_data() y __ip_append_data() son rutas de envío por paquete sin estado persistente entre llamadas, lo que hace que la corrección aritmética de upstream sea una adaptación limpia de kpatch.

Estado del canal de distribución (30 de junio de 2026, 09:00 UTC): Las versiones de EL10 han comenzado a incorporarse al canal de pruebas para RHEL 10, Oracle Linux 10, Rocky Linux 10 y AlmaLinux 10.

Aplicar desde el feed de prueba tras la validación:

sudo kcarectl --update --prefix test

Una vez que se haya publicado en el feed principal, aparecerá en la siguiente ejecución programada, o bien puedes publicarlo cuando quieras:

sudo kcarectl --update

Comprueba que el parche esté activo:

kcarectl --info | grep kpatch-build-time      # build dated 2026-06-30 or later

Una vez asignado un CVE, kcarectl --patch-info | grep CVE-2026- también debería aparecer. Por otra parte, si gestionas directamente los núcleos EL10, AlmaLinux ya cuenta con las correcciones de origen en el código fuente de su paquete de núcleo (6.12.0-211.28.2) a fecha de 30 de junio; conviene estar atento a tus repositorios y a los árboles de otros proveedores para encontrar las erratas correspondientes.

Detección

No existe ninguna señal clara que indique que se ha producido una explotación de este tipo de fallo. La cadena culmina en operaciones arbitrarias de lectura y escritura en el núcleo y puede desactivar la aplicación de SELinux, mientras que las comprobaciones de estado habituales siguen pareciendo tranquilizadoras y no se produce ningún cambio en el disco. Las señales que realmente se corresponden con el comportamiento de este exploit son de carácter conductual:

• Cambios inesperados en /proc/sys/kernel/core_pattern, sobre todo un |-controlador con el prefijo «-»: el PoC lo sobrescribe para ejecutar un «usermodehelper» como root.
• Un contenedor o un proceso hijo se bloquea justo antes de que se inicie un proceso con privilegios inusuales en el host.
• Lagunas en la auditoría de SELinux: la aplicación aparece como activa, pero dejan de aparecer los rechazos esperados en un host que debería generarlos.

Auditoría core_pattern y presta atención a la secuencia de «bloqueo seguido de ejecución con privilegios». Considéralas señales débiles más que pruebas. Ten en cuenta que este PoC elude el KASLR a través de la tabla de páginas fija de SMP-trampoline, por lo que no necesita leer /proc/kallsyms o BTF: esos indicadores clásicos de explotación del núcleo no aparecerán aquí. Si un usuario o una carga de trabajo no fiable o semiconfiable tuvo ejecución local en un host EL10 afectado durante el periodo de exposición, prioriza la aplicación de parches y asume que el host podría requerir una revisión más exhaustiva.

Por qué es importante este tema

«ipv6-frag-escape» no supone la ejecución remota de código, ni es un fallo que provoque que «todos los equipos Linux dejen de funcionar al instante». En el caso de los hosts de contenedores, las plataformas de alojamiento compartido, los sistemas de integración continua (CI), los entornos de pruebas para desarrolladores y los sistemas Linux multitenant, la gravedad del problema es aún mayor en un sentido más específico: derrumba precisamente el límite en torno al cual se han construido esas plataformas. El ataque comienza desde un proceso sin privilegios y termina con privilegios de root en los espacios de nombres iniciales del host.

Cuando existe una prueba de concepto (PoC) operativa antes de que se publique un CVE o una adaptación estable, el flujo de trabajo habitual de aplicación de parches basado en escáneres no tiene nada que detecte. Los responsables de la seguridad deben actuar directamente en función de los datos técnicos. La corrección es pequeña, pero la urgencia operativa no lo es.

Lista de verificación de medidas correctoras priorizadas

1. Aplica primero el parche —o el parche sin reinicio— a los sistemas EL10 afectados, especialmente a los hosts de contenedores y a cualquier lugar donde se pueda ejecutar código no fiable o semiconfiable.
2. Activar init_on_alloc=1 en los que aún no se haya implementado un kernel fijo o un parche que no requiera reinicio.
3. Desactiva los espacios de nombres de usuario sin privilegios siempre que la carga de trabajo lo permita.
4. Considera Ubuntu 24.04 y Debian 13 como «con fallos y sin acceso a las técnicas públicas actuales», no como versiones seguras.
5. Auditoría core_pattern y la actividad de denegación de SELinux en los hosts expuestos.
6. Supervisa la asignación de CVE y las errata posteriores de los proveedores, y vuelve a revisar los sistemas una vez que se hayan implementado las adaptaciones a versiones anteriores estables, incluso si la demostración de concepto pública nunca se ejecutó en tu entorno.

Referencias

• Demostración pública de concepto: https://github.com/sgkdev/ipv6_frag_escape
• Corrección de la fusión en el código fuente (7.2-rc1): https://github.com/torvalds/linux/commit/38becddc332c1dbee6ab8dc8f13a860c6280b905
• Solución para IPv6 736b380e28d0; Corrección de IPv4 eca856950f7c; activación de disparadores ce650a166335; que introduce errores 773ba4fe9104 (IPv6) / 8eb77cc73977 (IPv4)
• Adaptación del paquete del núcleo de AlmaLinux (6.12.0-211.28.2): servidor Git del sistema operativo AlmaLinux, confirmación 674503c679

Aplica parches a cualquier kernel sin necesidad de reiniciar. Si aún no eres usuario de KernelCare, ahora es un buen momento para descubrir cómo la aplicación de parches sin reinicio protege los sistemas Linux críticos sin necesidad de ventanas de mantenimiento de emergencia ni tiempos de inactividad.

Consigue KernelCare hoy mismo →