Cuatro exploits públicos del kernel de Linux ponen en riesgo de obtener root local a los hosts sin parchear

La disponibilidad de exploits funcionales eleva la urgencia

El investigador de seguridad Asim Manizada publicó el 18 de septiembre de 2026 los detalles técnicos y exploits funcionales de cuatro vulnerabilidades del kernel de Linux capaces de elevar privilegios locales hasta root.

Las vulnerabilidades son DirtyAH6 (CVE-2026-80844), TUNderflow (CVE-2026-81000), PPPoEject (CVE-2026-68121) y DiagSpill (CVE-2026-74469). Cada una afecta a una parte distinta de la pila de red del kernel, pero las cuatro implican una gestión insegura de la memoria en código con un alto nivel de privilegios.

Manizada comunicó las vulnerabilidades al equipo de seguridad del kernel de Linux a mediados de julio. Después coordinó el proceso con las distribuciones de Linux antes de publicar los exploits, lo que permitió a los mantenedores disponer de tiempo para distribuir las correcciones.

No se han notificado casos de explotación en entornos reales. Sin embargo, la publicación del código proporciona a los atacantes una base para adaptar estas técnicas a kernels de distribuciones sin parchear, especialmente en servidores multiusuario, infraestructuras compartidas y hosts de contenedores.

Los exploits publicados están ajustados a versiones concretas del kernel y pueden bloquear los sistemas objetivo. Es más preciso describirlos como herramientas de investigación de prueba de concepto que como implantes fiables, pero Manizada utilizó correctamente las vulnerabilidades subyacentes para obtener shells de root durante las pruebas.

Cuatro fallos en cuatro subsistemas de red

DirtyAH6 afecta a la implementación de la cabecera de autenticación de IPsec para IPv6. El código vulnerable reorganiza las direcciones de una cabecera de enrutamiento IPv6 antes de calcular o validar el valor de comprobación de integridad.

El problema se produce porque ipv6_rearrange_rthdr() confiaba en el campo segments_left de la cabecera de enrutamiento sin comprobar que coincidiera con el número de direcciones representadas por hdrlen. Con un paquete IPv6 sin procesar de tipo HDRINCL, hdrlen puede indicar una dirección mientras segments_left contiene un valor mucho mayor. Establecerlo en 255 desplaza 4.064 bytes hacia atrás un puntero interno de dirección, lo que provoca un acceso a memoria fuera de los límites y una posible escritura.

TUNderflow se encuentra en el código de red virtual TUN/TAP. Dentro de tun_get_user(), el kernel utilizaba tun->align tanto como espacio adicional en la cabecera del búfer de socket como en un cálculo para determinar qué cantidad de datos del paquete debía permanecer lineal.

Open vSwitch puede enviar desde otro puerto una solicitud de espacio adicional en la cabecera de tamaño excesivo. Si ese valor supera el área utilizable de la cabecera de un búfer de socket de una página, SKB_MAX_HEAD(align) sufre un underflow. Posteriormente, el valor intermedio negativo puede desbordarse al asignarse a un size_t sin signo, lo que permite que tun_alloc_skb() sitúe skb->data fuera del búfer asignado.

TUNderflow tiene una puntuación CVSS 3.1 de 7,8, con el vector CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H.

PPPoEject afecta a PPP sobre Ethernet. En pppoe_sendmsg(), el kernel guardaba un puntero a una cabecera PPPoE y después invocaba dev_hard_header(). Las devoluciones de llamada específicas del dispositivo pueden ampliar o reasignar la cabecera del búfer de socket, invalidando los punteros a la memoria original.

Una de las secuencias que desencadenan el fallo implica una operación de envío bloqueada en copy_from_user() mientras se añade el primer puerto que no es Ethernet a un dispositivo de tipo team vacío. A continuación, una devolución de llamada delegada para la cabecera GRE puede reubicar el búfer. Más tarde, PPPoE escribe seis bytes a través del puntero obsoleto en memoria liberada, lo que provoca una condición de uso después de liberación.

PPPoEject también tiene una puntuación de 7,8 según CVSS 3.1, con CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H.

DiagSpill es un fallo de desbordamiento de contador en sctp_diag. La función sctp_assoc_add_peer() incrementa un transport_count de 16 bits por cada peer SCTP único. Al añadir el transporte número 65.536, el contador vuelve a cero.

A continuación, el código de diagnóstico SCTP reserva una carga INET_DIAG_PEERS basándose en ese valor cero, pero sigue copiando todas las estructuras de transport_addr_list. El resultado es una escritura fuera de los límites de aproximadamente 8 MiB más allá del final del búfer de socket. La corrección rechaza nuevos peers únicos cuando transport_count alcanza U16_MAX.

DiagSpill tiene la puntuación más alta de las cuatro vulnerabilidades: 8,8, con CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H.

No hay disponible ninguna puntuación ni vector CVSS v3 para DirtyAH6.

Requisitos de acceso local y efectos remotos limitados

Por lo general, DirtyAH6, TUNderflow y PPPoEject requieren que estén habilitados los espacios de nombres de usuario sin privilegios. Esta función permite que una cuenta ordinaria adquiera capacidades similares a root dentro de un espacio de nombres aislado, incluidas las necesarias para acceder a rutas de red que normalmente están restringidas.

Por tanto, los tres fallos son especialmente relevantes en entornos donde los usuarios locales pueden crear sus propios espacios de nombres. Deshabilitar esta función puede eliminar el punto de entrada previsto para usuarios sin privilegios, aunque no protege los procesos ni los contenedores que ya dispongan de las capacidades necesarias para administrar la red.

DiagSpill es diferente. Manizada indicó que no requiere espacios de nombres de usuario ni privilegios especiales. No obstante, el vector de NVD asigna PR:L, lo que indica que se requieren pocos privilegios según su modelo de puntuación. Se desconoce el motivo de esta discrepancia.

El impacto remoto es más limitado que el riesgo de obtener root localmente. DirtyAH6 puede bloquear un router o gateway IPv6 que enrute tráfico IPv6 y añada una cabecera de autenticación IPsec en modo transporte. Manizada solo consiguió obtener root de forma remota después de preparar deliberadamente la memoria del objetivo en un laboratorio y consideró que explotar la vulnerabilidad sin esa preparación era extremadamente difícil.

DiagSpill puede bloquear un sistema de forma remota cuando están activas las opciones SCTP correspondientes, que no vienen habilitadas de forma predeterminada. No se encontró ninguna vía viable para obtener root de forma remota, ni siquiera bajo supuestos favorables sobre la disposición de la memoria.

No se ha comunicado ninguna vía directa de explotación remota para TUNderflow o PPPoEject. En teoría, los fallos podrían permitir escapar de un contenedor, pero no se desarrolló ni demostró ningún método de ese tipo.

Las correcciones completas empiezan con versiones estables concretas

Los mantenedores del kernel de Linux han corregido los cuatro fallos. Las primeras versiones estables de upstream que, según los informes, contienen el conjunto completo de parches son:

• 5.10.270
• 5.15.221
• 6.1.188
• 6.6.157
• 6.12.109
• 6.18.50
• 7.2.4

Estas cifras no deben compararse mecánicamente con las cadenas de versión del kernel que indican Debian, Ubuntu, Red Hat, SUSE u otras distribuciones. Los proveedores suelen aplicar parches de seguridad mediante backporting y conservar los números de versión base más antiguos.

Los administradores deben comprobar que el paquete del kernel de su distribución incluye las correcciones para los cuatro CVE. No se conocen los intervalos exactos de versiones vulnerables, las versiones de los paquetes de cada distribución ni los identificadores de los avisos de los proveedores.

Ninguna de las cuatro vulnerabilidades cuenta con una entrada notificada en el catálogo CISA Known Exploited Vulnerabilities ni con una fecha límite de corrección KEV. Esto coincide con la ausencia de ataques notificados, pero no reduce la exposición que genera la disponibilidad pública del código de los exploits.

Qué sistemas deben recibir prioridad

El parcheado debe comenzar por los sistemas donde usuarios no confiables puedan ejecutar código local o crear espacios de nombres. Entre los objetivos prioritarios se incluyen las plataformas de hosting compartido, los servidores de investigación, los equipos de desarrollo, los hosts de contenedores y otros entornos Linux multiusuario.

La exposición también es mayor cuando se utilizan activamente las funciones de red afectadas, como Open vSwitch, TUN/TAP, PPPoE, IPsec AH6, SCTP, los dispositivos team y la gestión delegada de cabeceras GRE.

Como medidas temporales de reducción del riesgo, los administradores pueden deshabilitar los espacios de nombres de usuario sin privilegios y eliminar las funciones de red que no se utilicen. Deshabilitar IPv6 AH6, TUN/TAP, PPPoE o SCTP puede impedir el acceso a determinadas rutas vulnerables.

Estas medidas no sustituyen a los kernels parcheados. Puede haber rutas de ejecución alternativas y DiagSpill no se soluciona deshabilitando los espacios de nombres de usuario.

La monitorización debe centrarse en la creación inesperada de espacios de nombres, nuevas configuraciones TUN/TAP o SCTP, actividad inusual de Open vSwitch y de dispositivos team, shells de root sin explicación y bloqueos del kernel relacionados con los subsistemas afectados. Puesto que las pruebas de concepto pueden desestabilizar un host, los fallos del kernel podrían ser una primera señal de pruebas o de un intento de explotación fallido.

La investigación asistida por IA encontró errores con décadas de antigüedad

Manizada utilizó análisis personalizados asistidos por IA para modelizar el comportamiento de la memoria del kernel y razonar sobre la disposición de los objetos. La corrección de DirtyAH6 incluye una atribución “Assisted-by” a esas herramientas.

Se estima que los errores de programación subyacentes tienen entre 10 y 21 años de antigüedad. Incluyen un campo de paquete sin validar, un underflow de enteros seguido de un desbordamiento sin signo, un puntero obsoleto conservado durante la reasignación de un búfer y un desbordamiento de un contador de 16 bits.

Manizada también había revelado en julio la vulnerabilidad OVSwrap de Open vSwitch. Uno de los nuevos exploits reutiliza una técnica de Dirty Frag, otra vulnerabilidad de root del kernel de Linux que otro investigador reveló en mayo.

La fiabilidad de los exploits públicos sigue siendo limitada. El avance más relevante es que los atacantes ya pueden estudiar rutas completas de explotación para cuatro fallos de red con privilegios elevados y adaptarlas a kernels de distribuciones ampliamente desplegadas. Aplicar parches cierra esa oportunidad de forma más fiable que la contención basada únicamente en la configuración.