El kernel de Linux, ese coloso de código que sostiene desde servidores en la nube hasta teléfonos Android, ha vuelto a demostrar que la seguridad no es un destino, sino una carrera permanente. Un investigador de seguridad ha publicado exploits funcionales para cuatro vulnerabilidades que permiten a un usuario local obtener privilegios de root, el nivel más alto de acceso en una máquina.
Los fallos, bautizados como DirtyAH6, TUNderflow, PPPoEject y DiagSpill, han sido corregidos por los mantenedores del kernel en las últimas semanas, pero el código de explotación ya está en la naturaleza, y cualquier sistema que aún ejecute un kernel antiguo está en riesgo.
El investigador, Asim Manizada, encontró las cuatro vulnerabilidades y las reportó al equipo de seguridad del kernel de Linux a mediados de julio. Tras una retención coordinada con las distribuciones para que los parches pudieran publicarse primero, Manizada publicó el 18 de septiembre un análisis técnico acompañado de exploits funcionales.
Hasta ahora, no hay informes de que estas vulnerabilidades hayan sido utilizadas en ataques del mundo real. Pero el código público eleva el riesgo, especialmente en sistemas compartidos donde un atacante ya tiene algún acceso, como una cuenta de bajos privilegios en un servidor multiusuario, y busca tomar el control total.
La anatomía de cuatro fallos que desnudan al kernel
Los cuatro fallos comparten una característica común: son errores de seguridad de memoria en diferentes partes del código de red del kernel. Cada uno permite a un atacante corromper la memoria del kernel, lo que Manizada aprovechó para obtener una shell de root. Los errores subyacentes son antiguos, con una antigüedad que oscila entre los 10 y los 21 años.
DirtyAH6 (CVE-2026-80844) reside en el código de IPsec que maneja la cabecera de autenticación de IPv6. El código confiaba en un campo de la cabecera de enrutamiento sin verificarlo contra el número de direcciones presentes, por lo que un paquete manipulado provocaba que un puntero interno se desplazara muy fuera de los límites y escribiera más allá del búfer.
Para explotarlo, un usuario normal necesita que los espacios de nombres de usuario no privilegiados estén habilitados, una característica de Linux que permite a un usuario normal actuar como root dentro de un sandbox privado. Muchas distribuciones los habilitan por defecto.
TUNderflow (CVE-2026-81000) se encuentra en los dispositivos de red virtuales TUN y TAP. Un único valor se utilizaba tanto como espacio libre como para el tamaño, y un valor sobredimensionado pasado a través de Open vSwitch provocaba que el cálculo del tamaño se desbordara, haciendo que los datos del paquete aterrizaran fuera de su búfer. También requiere espacios de nombres de usuario no privilegiados.
PPPoEject (CVE-2026-68121) está en el código de PPP sobre Ethernet. Mantenía un puntero a un búfer de red mientras llamaba a una rutina de dispositivo que podía liberar y mover ese búfer, y las escrituras posteriores utilizaban memoria liberada, un error conocido como use-after-free. Al igual que los dos anteriores, requiere espacios de nombres de usuario no privilegiados.
DiagSpill (CVE-2026-74469) es la excepción. No requiere espacios de nombres de usuario ni privilegios especiales, siempre que el sistema tenga disponible el módulo de red SCTP. El fallo está en el código de informes de SCTP.
Un contador que rastrea los puntos finales de conexión tiene solo 16 bits de ancho, por lo que el punto final número 65.536 lo hacía volver a cero. El código de informes entonces no reservaba espacio pero copiaba la lista completa, escribiendo unos 8 MiB de datos más allá del final de su búfer.
El alcance del daño: qué sistemas están en riesgo
Tres de los cuatro fallos pueden ser alcanzados por un usuario ordinario solo cuando los espacios de nombres de usuario no privilegiados están habilitados. El cuarto, DiagSpill, es el más peligroso en términos de requisitos, ya que no necesita privilegios especiales, solo que el módulo SCTP esté disponible.
Manizada también descubrió que dos de los fallos, DirtyAH6 y DiagSpill, pueden ser desencadenados a través de la red, pero solo en casos muy concretos y principalmente para provocar un bloqueo del sistema. DirtyAH6 puede bloquear un host que actúe como enrutador o puerta de enlace IPv6 y añada una cabecera de autenticación IPsec en modo transporte. DiagSpill puede bloquear un host solo cuando ciertas opciones de SCTP, que están desactivadas por defecto, están activadas.
El investigador alcanzó root remoto con DirtyAH6 solo en su propio laboratorio, y solo moldeando primero la memoria del objetivo. Hacerlo desde una posición remota únicamente, escribió, “parece extremadamente difícil”, aunque no lo descartó. Para DiagSpill, dijo que no ve ningún camino hacia root remoto, ni siquiera con un moldeado de memoria perfecto. También señaló que los fallos podrían, en teoría, permitir a un atacante escapar de un contenedor, pero no construyó uno.
La respuesta: actualizar es la única opción real
La recomendación de los mantenedores del kernel es clara: actualizar a un kernel que incluya las cuatro correcciones. Las primeras versiones estables del kernel de Linux con el conjunto completo de parches son la 5.10.270, 5.15.221, 6.1.188, 6.6.157, 6.12.109, 6.18.50 y 7.2.4.
Sin embargo, la mayoría de la gente no ejecuta un kernel del proyecto principal de Linux, sino uno de una distribución como Debian, Ubuntu, Red Hat o SUSE, que utiliza sus propios números de versión y añade estas correcciones según su propio calendario.
Los administradores deben consultar el aviso de seguridad de su distribución para confirmar que ha enviado una actualización que incluya los cuatro fallos, en lugar de limitarse a comparar los números de versión.
Si no se puede parchear de inmediato, hay dos pasos que reducen el riesgo. El primero es desactivar los espacios de nombres de usuario no privilegiados, lo que cierra el camino del usuario ordinario a DirtyAH6, TUNderflow y PPPoEject.
Aunque no detiene DiagSpill, ni detiene un contenedor o proceso que ya tenga privilegios de administración de red. El segundo es desactivar las características afectadas si no se utilizan: AH6, TUN/TAP, PPPoE y SCTP. Manizada recomienda parchear en lugar de desactivar características, porque pueden existir otras rutas hacia los mismos fallos.
La IA como herramienta de descubrimiento de vulnerabilidades
Uno de los aspectos más fascinantes de esta divulgación es cómo se encontraron los fallos. Manizada reveló que utilizó un proceso asistido por inteligencia artificial que construye un mapa de cómo el kernel maneja la memoria y razona sobre su diseño. La corrección del kernel para DirtyAH6 lo registra: el commit incluye una línea “Assisted-by” que acredita sus herramientas de IA personalizadas.
Este es el último de una serie de fallos de escalada de privilegios en el kernel de Linux divulgados a lo largo de 2026, varios de ellos encontrados con la ayuda de modelos de lenguaje grandes. Manizada divulgó un fallo similar en Open vSwitch, OVSwrap, en julio.
Uno de los nuevos exploits también reutiliza una técnica de Dirty Frag, otro fallo de root en el kernel de Linux divulgado en mayo por un investigador diferente. En su análisis, Manizada dijo que este lote probablemente pone fin a la fase pública de su caza de errores asistida por IA.
El contexto: una carrera que no se detiene
La divulgación de estos cuatro fallos es un recordatorio de que la seguridad del kernel de Linux es un proceso continuo, no un estado final. Los errores son antiguos, algunos con más de dos décadas de antigüedad, y han permanecido ocultos a pesar de la revisión constante de miles de desarrolladores en todo el mundo. La llegada de herramientas de IA capaces de analizar código a una escala y velocidad sin precedentes está cambiando el juego, tanto para los atacantes como para los defensores.
Para los administradores de sistemas, la lección es clara: la actualización del kernel no es una tarea que pueda posponerse indefinidamente. En un mundo donde los exploits se publican en cuestión de semanas tras la divulgación, y donde las herramientas de IA aceleran el descubrimiento de vulnerabilidades, la ventana de exposición se ha reducido drásticamente. La seguridad no es un producto, sino un proceso. Y en ese proceso, la velocidad de respuesta es tan importante como la calidad de las defensas.
Manizada ha hecho su parte: encontrar los fallos, reportarlos y esperar a que se publiquen los parches antes de divulgar los exploits. Ahora les toca a los administradores hacer la suya: actualizar antes de que alguien con malas intenciones aproveche el código público para atacar. La pelota está en su tejado. Y el reloj ya está corriendo.
Descubre más desde CIBERED
Suscríbete y recibe las últimas entradas en tu correo electrónico.
