Cuatro vulnerabilidades descubiertas en distintos subsistemas de red del kernel de Linux permiten convertir una cuenta local sin privilegios en acceso de root en los sistemas afectados. Los fallos, bautizados como DirtyAH6, TUNderflow, PPPoEject y DiagSpill y registrados como CVE-2026-80844, CVE-2026-81000, CVE-2026-68121 y CVE-2026-74469, fueron divulgados públicamente el 18 de septiembre de 2026 después de finalizar el periodo de embargo.
Las claves de las cuatro vulnerabilidades de Linux en 20 segundos
- Cuatro fallos afectan a XFRM/AH6, TUN, PPPoE y SCTP del kernel de Linux.
- Los cuatro permiten elevar privilegios de un usuario local hasta root en los objetivos afectados.
- Las tres primeras vulnerabilidades dependen de espacios de nombres de usuario/red sin privilegios o determinadas capacidades.
- DiagSpill no necesita espacios de nombres sin privilegios y puede provocar además una denegación de servicio remota en determinadas configuraciones.
- Las correcciones ya han llegado a varias ramas estables, desde Linux 5.10 hasta las versiones más recientes.
El investigador Asim Manizada comunicó los cuatro problemas a los responsables del kernel y a los mantenedores correspondientes a mediados de julio. Según su análisis, los errores originales llevaban entre 10 y 21 años presentes en el código. El anuncio público llegó después de que expirase el embargo coordinado con la lista linux-distros.
El dato más relevante para administradores no es tanto la antigüedad de los errores como que los cuatro cuentan con pruebas de concepto públicas que demuestran una escalada local hasta root. Red Hat ha clasificado el conjunto como vulnerabilidades de impacto importante y está acelerando la distribución de correcciones para sus sistemas afectados.
Cuatro errores, cuatro partes distintas del kernel
Las vulnerabilidades no proceden de un único componente. Cada una afecta a una parte diferente de la pila de red de Linux y tiene unos requisitos concretos.
| Vulnerabilidad | CVE | Subsistema | Requisito destacado |
|---|---|---|---|
| DirtyAH6 | CVE-2026-80844 | IPv6 AH/XFRM | AH6/XFRM y namespace de usuario/red o determinadas capacidades |
| TUNderflow | CVE-2026-81000 | TUN/TAP | TUN y una ruta de red capaz de propagar un headroom excesivo |
| PPPoEject | CVE-2026-68121 | PPPoE | PPPoE y una devolución de cabecera que pueda realocar el skb |
| DiagSpill | CVE-2026-74469 | SCTP/sctp_diag | SCTP y sctp_diag, sin necesidad de namespace de usuario |
La tabla refleja los requisitos descritos por el investigador y las confirmaciones publicadas por los mantenedores y distribuidores. No significa que cualquier instalación de Linux sea automáticamente explotable: las pruebas de concepto tienen dependencias adicionales y están dirigidas a determinados sistemas y configuraciones.
DirtyAH6: un problema en IPv6 y AH6
DirtyAH6 afecta al procesamiento de cabeceras de enrutamiento IPv6 dentro de AH6, el mecanismo de autenticación de IPsec. El problema aparece cuando el kernel calcula el número de direcciones a partir de hdrlen pero no comprueba adecuadamente que segments_left se encuentre dentro de ese límite.
Según el análisis publicado, un paquete IPv6 construido con determinados valores podía provocar que el kernel desplazara un puntero miles de bytes hacia atrás y ejecutara un memmove() fuera de los límites esperados. El fallo está identificado como CVE-2026-80844.
El investigador también consiguió demostrar impacto remoto en circunstancias muy concretas cuando el sistema actúa como router o gateway IPv6 y utiliza AH en modo transporte. En laboratorio llegó a obtener ejecución remota como root mediante técnicas adicionales de manipulación de memoria, aunque considera que conseguirlo únicamente de forma remota sería extremadamente difícil.
TUNderflow: cuando el tamaño del headroom rompe los límites
TUNderflow, CVE-2026-81000, afecta al dispositivo TUN y al tratamiento del espacio reservado delante de los datos de un paquete. El problema estaba relacionado con el uso del parámetro tun->align tanto para calcular el espacio de cabecera como para determinar cuánto contenido debía mantenerse en la parte lineal del skb.
La cadena descrita por el investigador puede involucrar Netkit, VXLAN y Open vSwitch (OVS), que pueden propagar una solicitud de headroom excesivamente grande hasta TUN. En determinadas condiciones, el cálculo podía sufrir un underflow y terminar colocando skb->data fuera del área asignada.
Debian recoge la corrección upstream, que limita el headroom almacenado por TUN al presupuesto disponible para la cabecera del skb y corrige además el tratamiento de paquetes no lineales.
PPPoEject: un puntero que deja de apuntar donde debería
PPPoEject, CVE-2026-68121, se encuentra en el procesamiento de PPPoE. El kernel conservaba un puntero hacia la cabecera del paquete antes de llamar a dev_hard_header(), aunque esa operación puede provocar una realocación de la cabecera del skb.
Si la memoria se mueve, el puntero anterior deja de ser válido. El código posterior podía seguir utilizándolo para escribir información sobre una zona de memoria que ya no correspondía al skb original.
Red Hat documenta una situación especialmente concreta en la que la realocación podía producirse mientras una operación de copia estaba bloqueada y se añadía un puerto a determinados dispositivos de red. La corrección consiste en volver a obtener la dirección de la cabecera utilizando el desplazamiento almacenado en el skb.
DiagSpill: un contador de 16 bits que termina desbordándose
DiagSpill, CVE-2026-74469, presenta una característica diferente. Afecta al subsistema SCTP y a su interfaz de diagnóstico sctp_diag.
Una asociación SCTP puede llegar a tener 65.536 transportes de pares, pero el contador utilizado por el kernel tenía una capacidad de 16 bits. Al alcanzar ese límite, el contador podía volver a cero. Posteriormente, sctp_diag calculaba el espacio necesario utilizando ese valor incorrecto, pero continuaba recorriendo y copiando toda la lista de transportes.
El resultado podía ser una escritura de aproximadamente 8 MiB fuera del búfer previsto, según la documentación de Red Hat.
DiagSpill es además el caso que presenta una diferencia importante respecto a los otros tres fallos: no necesita un namespace de usuario sin privilegios ni capacidades especiales para su explotación local, siempre que estén disponibles SCTP y sctp_diag. En determinadas configuraciones con ASCONF/ADD-IP, SCTP-AUTH o la opción net.sctp.addip_noauth_enable=1, también puede ser provocado remotamente para causar una caída o denegación de servicio.
Las versiones corregidas ya están disponibles
El investigador señala como primeras versiones estables que incorporan las cuatro correcciones las ramas 5.10.270, 5.15.221, 6.1.188, 6.6.157, 6.12.109, 6.18.50 y 7.2.4. Los distribuidores, sin embargo, publican sus propias versiones corregidas y calendarios de actualización, por lo que no basta con mirar únicamente el número upstream del kernel.
El caso de Debian muestra por qué conviene comprobar la versión proporcionada por cada distribución. Para varias de estas vulnerabilidades, Debian Bookworm fija el problema en paquetes de kernel concretos, mientras que las ramas Trixie, Forky y Sid tienen otros números de paquete y estados de corrección.
Los administradores deberían comprobar primero qué kernel está ejecutando cada sistema y consultar después el boletín de seguridad de su distribución. En servidores Linux utilizados como nodos de virtualización, infraestructura de red o sistemas multiusuario, esta revisión tiene especial importancia porque el escenario de amenaza local puede incluir usuarios, contenedores o procesos con determinadas capacidades.
Como mitigación temporal, el investigador propone desactivar los espacios de nombres de usuario sin privilegios cuando la configuración lo permita, aunque esa medida no cubre DiagSpill y tampoco protege frente a procesos o contenedores que ya dispongan de las capacidades necesarias. Otra opción consiste en desactivar AH6, TUN, PPPoE o SCTP/sctp_diag cuando no sean necesarios.
Red Hat coincide en recomendar la actualización a kernels corregidos y señala específicamente que restringir los espacios de nombres de usuario sin privilegios reduce la superficie de ataque de las tres primeras vulnerabilidades, pero no elimina el riesgo asociado a DiagSpill.
La publicación también incluye código de prueba para las cuatro vulnerabilidades en repositorios independientes. Es una información útil para equipos de seguridad que necesiten validar sus sistemas, pero la existencia de estos PoC hace todavía más importante que las comprobaciones se realicen sobre entornos controlados y que los sistemas de producción reciban las actualizaciones correspondientes.
El caso deja además una particularidad interesante: los cuatro errores pertenecen a componentes de red con historias y funciones muy diferentes, y algunos llevaban más de una década en el kernel. Eso demuestra que la antigüedad del código no permite por sí sola determinar si una pieza está fuera del alcance de nuevas investigaciones de seguridad. La respuesta práctica para los administradores sigue siendo conocer qué módulos están activos, reducir los componentes innecesarios y mantener los kernels y paquetes de seguridad actualizados.
Preguntas frecuentes
¿Qué son DirtyAH6, TUNderflow, PPPoEject y DiagSpill?
Son cuatro vulnerabilidades del kernel de Linux identificadas como CVE-2026-80844, CVE-2026-81000, CVE-2026-68121 y CVE-2026-74469. Afectan respectivamente a AH6/XFRM, TUN, PPPoE y SCTP/sctp_diag.
¿Permiten obtener acceso root en Linux?
Sí. Las pruebas de concepto publicadas por el investigador demuestran escalada desde un usuario local sin privilegios hasta root en los objetivos afectados. Las condiciones concretas de explotación dependen de cada vulnerabilidad y de la configuración del kernel.
¿Qué versiones de Linux están corregidas?
Las primeras ramas estables que contienen las cuatro correcciones son 5.10.270, 5.15.221, 6.1.188, 6.6.157, 6.12.109, 6.18.50 y 7.2.4. Las distribuciones Linux pueden aplicar las correcciones mediante versiones de paquete diferentes, por lo que deben consultarse sus propios boletines de seguridad.
¿Es necesario tener habilitados todos los componentes afectados?
No. Cada vulnerabilidad tiene requisitos diferentes. Desactivar AH6, TUN, PPPoE o SCTP/sctp_diag cuando no sean necesarios puede reducir la superficie de ataque, pero la actualización del kernel sigue siendo la medida principal.
