El kernel de Linux es la capa que conecta el hardware con todo lo demás, y está debajo de una cantidad enorme de infraestructura: servidores, nubes públicas, teléfonos, routers y supercomputadoras. Por eso un fallo ahí no se parece a un fallo en una aplicación cualquiera, y por eso cada tanda de correcciones importa más de lo que su discreción sugiere.
Septiembre dejó tres frentes abiertos a la vez. Red Hat agrupó cuatro vulnerabilidades de la pila de red que, cumpliéndose ciertas condiciones, permiten que un usuario local llegue a root. Ubuntu publicó su propia tanda de parches para un conjunto distinto de fallos. Y mientras tanto, el desarrollo de Linux 7.3 avanzó hasta su quinta versión candidata, con un detalle nuevo en el historial de cambios: parches que llevan escrito que los encontró una inteligencia artificial.
Claves del mes en el kernel
- Cuatro fallos de escalada a root: Red Hat los agrupó el 19 de septiembre en el aviso RHSB-2026-011, actualizado el día 26. Afectan a la infraestructura de red del kernel y alcanzan a Red Hat Enterprise Linux 6 a 10 y a OpenShift.
- Tienen nombre: DirtyAH6 (CVE-2026-80844), TUNderflow (CVE-2026-81000), PPPoEject (CVE-2026-68121) y DiagSpill (CVE-2026-74469). Tocan, respectivamente, el subsistema IPv6 AH6/XFRM, el controlador TUN/TAP, la ruta de transmisión de PPPoE y los diagnósticos de SCTP.
- Ubuntu fue por su cuenta: el 30 de septiembre publicó USN-8851-1, con correcciones para el servidor NFS, IPv6 y Netfilter (CVE-2026-53221, CVE-2026-53131 y CVE-2025-38724), en Ubuntu 20.04 y 18.04 LTS. Incluye los kernels específicos para AWS, Azure, Google Cloud y Oracle Cloud, y exige reiniciar para que surtan efecto.
- Linux 7.3-rc5: publicado el 27 de septiembre. Es una candidata, todavía no la versión estable. La rama estable sigue en 7.2.8, del día 25.
- Parches con firma de IA: el subsistema IPE incorporó el 23 de septiembre dos correcciones de use-after-free marcadas con la etiqueta
Assisted-by: LLM.
Cuatro vulnerabilidades con nombre propio
Las cuatro comparten el mismo patrón: un usuario sin privilegios que ya tiene acceso a la máquina puede, si se cumplen los requisitos de cada una, terminar con permisos de administrador. No son fallos que permitan entrar desde fuera, pero sí convertir un acceso menor en control total.
La distinción importa poco en un servidor compartido. Cuando varios usuarios, contenedores y servicios corren sobre el mismo kernel, la frontera entre ellos es el kernel: si esa frontera cede, se cae todo el esquema de aislamiento de una vez. Red Hat señala un caso aparte, DiagSpill, que no necesita espacios de nombres de usuario sin privilegios y que en ciertas configuraciones de SCTP podría provocar además una denegación de servicio remota.
La empresa dice haber publicado ya las correcciones para buena parte de sus líneas de producto y estar acelerando las restantes.Fuente: Red Hat, RHSB-2026-011
Actualizar el kernel no es lo mismo que cambiar de versión
Aquí hay una confusión frecuente. Corregir una vulnerabilidad del kernel casi nunca significa instalar a mano una versión nueva desde kernel.org: cada distribución mantiene su propia rama y aplica los parches sobre ella. El resultado es que el número de versión puede quedarse igual mientras el fallo ya está corregido.
El aviso de Ubuntu lo ilustra bien. Además de los kernels genéricos, publica paquetes distintos para cada nube —linux-aws, linux-azure, linux-gcp, linux-oracle—, porque esos entornos usan kernels adaptados. Y advierte algo que se pasa por alto con facilidad: instalar la actualización no basta, hay que reiniciar para que el kernel nuevo entre en servicio.Fuente: Ubuntu Security Notice USN-8851-1
Por eso la pregunta útil no es «qué distribución tengo», sino «qué versión del kernel estoy ejecutando ahora mismo y qué actualizaciones de seguridad publica mi distribución para esa rama».
Linux 7.3 se acerca
Mientras las distribuciones tapan agujeros, la siguiente versión sigue su curso. Linux 7.3-rc5 salió el 27 de septiembre con correcciones repartidas por controladores, red, arquitectura, virtualización, BPF, sistemas de archivos y gráficos. Al ser una candidata, todavía faltan algunas semanas de pruebas antes de la versión definitiva.Fuente: kernel.org
En paralelo hay trabajo de mantenimiento menos visible pero con efectos medibles. Una serie de parches propone resincronizar el código de compresión LZ4 del kernel con el del proyecto original, del que llevaba años separado. Las mediciones publicadas junto a la serie reportan mejoras de entre 11% y 14% en algunas pruebas con el sistema de archivos EROFS, y de hasta 21% en escenarios concretos. Conviene leer esas cifras con cuidado: corresponden a pruebas puntuales, no a una mejora general, y la serie todavía no está integrada en la rama principal.
La IA ya deja su firma en los parches
El cambio más interesante del mes no es una función de Linux 7.3, sino cómo se están encontrando algunos errores. El kernel tiene decenas de millones de líneas y una maraña de interacciones entre subsistemas; hay fallos que un humano tardaría muchísimo en ver.
El 23 de septiembre, el subsistema IPE (Integrity Policy Enforcement) incorporó dos correcciones de use-after-free: una protege el hash raíz de dm-verity con RCU, y la otra evita que una política recién cargada se libere mientras se está auditando. Ambas llevan la etiqueta Assisted-by: LLM en el mensaje del commit, y ambas están marcadas para retroportarse a las ramas estables.
Hay un detalle revelador en uno de esos mensajes: una nota del mantenedor indica que se quitó el nombre del modelo «según la directriz más reciente». Es decir, la comunidad del kernel no solo acepta ya estas contribuciones, sino que está escribiendo reglas sobre cómo deben declararse.
Conviene no exagerar lo que significa. La IA no está sustituyendo a los mantenedores: actúa como una herramienta más para rastrear patrones sospechosos, errores de manejo de memoria o condiciones de carrera en una base de código gigantesca. Cada hallazgo sigue pasando por revisión humana, pruebas y la firma de un desarrollador que se hace responsable de él.
En la misma línea, los desarrolladores discuten añadir al árbol de código un archivo AGENTS.md, el formato que se usa para darle instrucciones a los agentes de programación. La propuesta surgió al ver que algunos agentes interpretaban mal las convenciones del proyecto, incluidas las etiquetas de autoría y certificación de los parches. Todavía no está en el árbol oficial, pero la discusión marca un cambio de fondo: los proyectos empiezan a documentar no solo cómo debe trabajar una persona, sino también cómo debe comportarse una máquina que colabora.
Por qué importa
Para quien usa Linux en el escritorio, casi nada de esto se nota: la distribución integra las correcciones y llegan con las actualizaciones normales. En servidores la historia cambia, porque una máquina puede pasar meses encendida dando servicio y el parche instalado no sirve de nada hasta que se reinicia.
Detrás de los tres frentes de este mes hay una misma dinámica. Linux soporta cada vez más hardware, arquitecturas y tecnologías, así que es cada vez más complejo; cuanto más complejo, más herramientas automáticas hacen falta para mantenerlo seguro —fuzzers, analizadores estáticos y ahora modelos de lenguaje—; y cuanto mejores son esas herramientas, más errores salen a la luz. Los avisos de seguridad no son señal de que el kernel esté peor, sino de que se está mirando con más lupa.
Para los administradores, el mensaje práctico no ha cambiado en veinte años: mantener el kernel actualizado y reiniciar cuando toca sigue siendo de las tareas de seguridad más básicas y más pospuestas. Lo que sí cambió es quién encuentra los fallos. Que dos parches del kernel lleven escrito que los halló un modelo de lenguaje, y que exista una directriz sobre cómo declararlo, dice bastante sobre hacia dónde va el desarrollo de software: la IA ya no solo corre sobre Linux, también ayuda a construirlo.
Fuentes: Red Hat RHSB-2026-011, Ubuntu USN-8851-1, kernel.org y el árbol de código del kernel. Imagen: Tux, mascota de Linux (CC0, Wikimedia Commons, basado en el diseño de Larry Ewing).