La inteligencia artificial está cambiando la forma de buscar errores en el kernel de Linux, pero también está creando un problema inesperado: los mantenedores reciben más hallazgos y parches de los que pueden revisar con comodidad. La documentación oficial del kernel reconoce que una parte importante de los informes de seguridad procede ya de análisis asistidos por IA y advierte de que muchos generan trabajo innecesario por su baja calidad o precisión.
Las claves de la IA y los fallos de Linux en 30 segundos
- El número de CVE corregidas por versión de Linux se acerca a las 2.000, frente a unas 500 durante buena parte de Linux 6.x.
- La IA permite revisar continuamente partes del kernel que antes recibían poca atención.
- Más CVE no significa necesariamente que Linux sea ahora menos seguro.
- Los mantenedores de red gestionaron 632 parches en
nety 648 ennet-nextpara Linux 7.3. - Entre un tercio y la mitad de los de
net-nextparecían correcciones o limpiezas de baja prioridad impulsadas por IA.
Linux 7.3 acaba de comenzar su fase de pruebas. Linus Torvalds publicó Linux 7.3-rc1 el 30 de agosto de 2026, mientras Linux 7.2.2 continúa como última versión estable.
El nuevo ciclo llega acompañado de un debate que está creciendo dentro del desarrollo del kernel: qué hacer cuando encontrar un posible fallo se vuelve barato y automatizable, pero comprobarlo sigue necesitando tiempo de especialistas.
La IA está modificando precisamente esa relación.
Más CVE no significa necesariamente un Linux menos seguro
El aumento del número de vulnerabilidades puede resultar alarmante visto únicamente como una estadística.
Durante buena parte de la generación Linux 6.x se contabilizaban aproximadamente 500 CVE corregidas por versión. La cifra superó posteriormente las 1.000 y con Linux 7.2 pasó de las 1.500. Si continúa la tendencia observada, Linux 7.3 podría acercarse o superar las 2.000.
Pero interpretar ese crecimiento como una degradación equivalente de la seguridad sería demasiado simplista.
Una parte del aumento procede de una capacidad mucho mayor para examinar código que anteriormente podía pasar años sin recibir una revisión profunda.
Los grandes modelos de lenguaje, analizadores estáticos y otras herramientas automatizadas pueden recorrer continuamente millones de líneas buscando condiciones de carrera, problemas con memoria, validaciones insuficientes, errores en el tratamiento de valores o situaciones excepcionales.
También pueden hacerlo sobre controladores antiguos, sistemas de archivos poco utilizados e interfaces que reciben mucha menos atención humana que los componentes más activos del kernel.
El resultado inevitable es encontrar más cosas.
El problema es que una herramienta puede señalar una situación sospechosa, pero eso no convierte automáticamente el hallazgo en una vulnerabilidad explotable.
La propia documentación oficial del kernel insiste en esta diferencia. La mayoría de los problemas enviados al equipo de seguridad son en realidad errores convencionales incorrectamente clasificados como problemas de seguridad, normalmente porque quien los reporta no ha interpretado adecuadamente el modelo de amenazas de Linux.
Para que un informe resulte útil hay que identificar las versiones afectadas, describir el problema, especificar las condiciones necesarias para provocarlo y proporcionar una forma de reproducirlo.
Con los hallazgos asistidos por IA los requisitos son incluso más importantes.
La documentación advierte expresamente de que estos informes suelen presentar varios defectos: textos excesivamente largos, consecuencias teóricas inventadas, reproducciones que no funcionan y problemas detectados en código tan antiguo o poco utilizado que su relevancia práctica puede ser mínima.
Es decir, la IA puede multiplicar la capacidad de buscar errores, pero también multiplica el ruido.
Los mantenedores de red reconocen estar desbordados
El subsistema de red proporciona uno de los ejemplos más claros de lo que está ocurriendo.
Durante la ventana de integración de Linux 7.3, los mantenedores Jakub Kicinski y Paolo Abeni gestionaron aproximadamente 632 parches para net y otros 648 para net-next.
Kicinski calculó que entre un tercio y la mitad de los 648 parches de net-next parecían correcciones de baja prioridad, limpiezas o aclaraciones relacionadas con el uso de inteligencia artificial.
Su descripción de la situación fue especialmente clara: estaban “completamente desbordados”.
Eso no significa que todos esos parches fueran incorrectos.
De hecho, ahí está parte del problema. Una herramienta automatizada puede descubrir un error técnicamente real en una situación extremadamente rara. Puede encontrar una condición de carrera en una API antigua, una anomalía que aparece durante un error PCIe poco habitual o un problema en un controlador utilizado por muy pocas máquinas.
Corregirlo puede ser razonable.
Pero cada parche sigue necesitando revisión, pruebas y una decisión humana sobre si la modificación es correcta y si merece introducirse en un componente tan sensible como el kernel.
La capacidad para generar propuestas está creciendo más rápidamente que la capacidad humana disponible para evaluarlas.
Los responsables de red están recurriendo curiosamente a la misma tecnología para intentar controlar el problema.
Kicinski explicó que cuentan con presupuesto y acceso proporcionados por Meta para revisar cada parche mediante varios modelos avanzados antes de la revisión humana. El proceso permite eliminar algunas alucinaciones, aunque el propio mantenedor reconoce que los modelos solo pueden ayudar hasta cierto punto.
La idea para próximos ciclos es trasladar a los modelos una parte del trabajo más mecánico: gestión de Patchwork, comprobaciones habituales del proceso, edición de mensajes de commit y posiblemente determinadas operaciones con parches que ya hayan recibido la aprobación de desarrolladores de confianza.
Linux empieza así a encontrarse con una situación paradójica: utilizar IA para gestionar parte del trabajo generado por la propia IA.
El kernel endurece las reglas para los fallos descubiertos con IA
Los responsables de seguridad de Linux no están rechazando el uso de inteligencia artificial para analizar código.
Su documentación reconoce explícitamente que puede resultar eficiente para encontrar errores en zonas que rara vez son examinadas. Pero también establece condiciones bastante estrictas para evitar trasladar al mantenedor todo el trabajo de comprobación.
Un informe generado con ayuda de IA debe verificarse contra una versión reciente del kernel. El problema debe poder reproducirse y, cuando sea posible, el investigador debería proporcionar también una corrección probada.
Además, Linux introduce una consideración peculiar: si se ha utilizado IA para descubrir un problema, el equipo de seguridad indica que debe tratarse como si fuese público.
La explicación es práctica. Según la experiencia recogida en la documentación del kernel, diferentes investigadores que utilizan herramientas similares pueden encontrar simultáneamente los mismos errores, incluso el mismo día.
El kernel pide también que los informes producidos mediante IA sean breves y estén escritos en texto plano.
No es un detalle menor.
Los mantenedores explican que reciben informes generados automáticamente con múltiples secciones, Markdown y extensas explicaciones especulativas. Ese formato obliga a dedicar más tiempo a localizar la información realmente necesaria: archivo afectado, versiones, impacto demostrado y forma de reproducir el fallo.
También se pide evitar especulaciones sobre consecuencias de seguridad.
Si un error permite obtener un privilegio concreto, el informe debe demostrarlo. Un modelo no debería rellenar el documento con posibles escenarios de ataque que no han sido comprobados.
La documentación llega incluso a recomendar cuestionar seriamente la validez de un informe cuando la herramienta de IA no consigue producir un reproductor funcional.
Esta política refleja una distinción cada vez más importante en el desarrollo de software: detectar algo sospechoso no equivale a demostrar un fallo de seguridad.
La IA está reduciendo enormemente el coste del primer paso. Los siguientes continúan siendo caros.
Ese desequilibrio podría tener consecuencias también para otros grandes proyectos de código abierto.
Cuando una persona necesitaba horas o días para encontrar, analizar y documentar un error, existía una limitación natural sobre el volumen de informes. Un agente puede ejecutar búsquedas de manera continua y generar posibles correcciones a una escala completamente diferente.
Los proyectos tendrán que decidir qué merece revisión humana.
Linux ya está empezando a hacerlo mediante requisitos más estrictos para los informes, automatización de parte del filtrado y eliminación progresiva de código cuyo mantenimiento deja de compensar su utilidad.
El resultado también obliga a interpretar de otra manera las estadísticas de vulnerabilidades.
Un sistema que pasa de registrar 500 a cerca de 2.000 CVE por versión puede parecer cuatro veces más inseguro si únicamente se observa el contador. También puede significar que se está examinando mucho más código y encontrando problemas que anteriormente permanecían ocultos.
La inteligencia artificial está haciendo precisamente eso con Linux.
El desafío que aparece ahora ya no consiste únicamente en conseguir que las máquinas encuentren errores. Consiste en disponer de suficientes humanos capaces de decidir cuáles importan.
Preguntas frecuentes
¿Linux tiene ahora más vulnerabilidades por culpa de la inteligencia artificial?
El aumento de CVE no demuestra por sí solo que el kernel sea menos seguro. Parte del crecimiento está relacionado con una mayor capacidad para detectar errores mediante herramientas automatizadas y revisiones asistidas por IA.
¿Cuántas CVE puede alcanzar Linux 7.3?
La tendencia reciente apunta hacia aproximadamente 2.000 CVE corregidas por versión, aunque Linux 7.3 está actualmente en fase RC y su cifra final todavía no puede darse por cerrada.
¿Por qué los mantenedores están preocupados por los informes generados con IA?
Porque cada posible problema necesita ser comprobado. Los informes incorrectos, irrelevantes o mal documentados consumen tiempo que podría dedicarse a errores reales y de mayor importancia.
¿Linux permite utilizar IA para encontrar vulnerabilidades?
Sí, pero exige que los hallazgos sean verificados. La documentación recomienda trabajar sobre código actualizado, reproducir el problema, preparar una corrección probada cuando sea posible y presentar informes concisos con información verificable.
