El kernel de Linux se acerca a un número récord de vulnerabilidades corregidas por versión. Según recoge Tom’s Hardware, el kernel se acerca a 2.000 CVE corregidos por versión, frente a las cerca de 500 que era habitual durante buena parte de la era Linux 6.x.
El dato procede de un informe de Phoronix del 28 de agosto, que recoge una diapositiva del mantenedor de Linux stable Greg Kroah-Hartman pensada para una presentación en Kernel Recipes 2026. Según esa diapositiva, los CVE superaron los 1.000 con Linux 7.0 y los 1.500 con Linux 7.2, y si la tendencia continúa, Linux 7.3 podría superar los 2.000.
El aumento no se debe a que el kernel sea menos seguro, sino a quién lo está mirando
Según explica la fuente, la subida no refleja un cambio en la seguridad de Linux ni un repunte real de vulnerabilidades, sino que «detectives» equipados con herramientas de IA están rastreando el árbol de código fuente del kernel, que supera los 40 millones de líneas tras 35 años de historia. Estas herramientas revisan secciones oscuras que los humanos rara vez vuelven a tocar, y de vez en cuando encuentran defectos genuinos: los registros de CVE de este año ya atribuyen explícitamente a análisis estático asistido por IA el hallazgo de vulnerabilidades después confirmadas por Intel Product Security.
El problema es que, según la fuente, muchos de esos hallazgos son vulnerabilidades de baja prioridad, a menudo en código de controladores poco usados, parches cuestionables o directamente alucinaciones, y son los mantenedores humanos quienes tienen que separar el trabajo útil del ruido.
«Estamos completamente desbordados», dice el mantenedor de red de Linux
En el ciclo de Linux 7.3, el mantenedor de red Jakub Kicinski calculó que entre un tercio y la mitad de los 648 parches gestionados en net-next eran correcciones de baja prioridad, limpiezas o aclaraciones impulsadas por IA. «We are completely overwhelmed», escribió Kicinski, algo que la fuente traduce como que el equipo está completamente desbordado.
La avalancha de hallazgos está acelerando la retirada de controladores antiguos
El aluvión también ha llevado a los mantenedores a plantearse si merece la pena seguir manteniendo controladores de décadas de antigüedad. En abril, el desarrollador Andrew Lunn propuso eliminar casi 28.000 líneas de código de red heredado, correspondiente a hardware de la era ISA y PCMCIA que apenas tenía usuarios pero que empezaba a generar hallazgos de IA que los mantenedores estaban obligados a investigar. Linux 7.3 retira código de controladores antiguos de SGI e IBM, y el controlador del sistema de archivos FreeVxFS se eliminó después de que su mantenedor señalara que ese código de compatibilidad ya solo servía de «alimento» para comprobadores automáticos de bugs.
El kernel responde combatiendo la IA con más IA
La comunidad del kernel no rechaza la IA sin más: el propio Kroah-Hartman ha usado herramientas de fuzzing asistidas por IA ejecutadas en local para encontrar bugs reales. El problema, según la fuente, es el resultado de IA sin verificar que se vuelca sobre los humanos para que lo validen. Por eso Kroah-Hartman ha vetado los parches generados por LLM en el subsistema staging del kernel, salvo para correcciones de seguridad legítimas, y la guía actualizada del proyecto advierte de que los informes generados por IA sin verificación humana pueden hacer perder el tiempo a los mantenedores. El equipo ha conseguido además acceso a varios modelos de frontera para ayudar a revisar parches y filtrar resultados alucinados.
Qué significa esto para quien sigue la seguridad de Linux
Para quien administra sistemas Linux o simplemente sigue de cerca su seguridad, el dato clave no es la cifra en sí, sino cómo leerla: ver 2.000 CVE en una versión no significa que el kernel se haya vuelto de repente más inseguro, sino que ahora hay muchas más manos —y modelos— buscando en el mismo código. Eso complica la tarea habitual de priorizar avisos de seguridad: el ruido de hallazgos de baja prioridad o directamente inventados puede ocultar los pocos hallazgos que sí importan, como los ya confirmados por Intel Product Security. La consecuencia práctica, y la que más debería preocupar a quien depende de hardware antiguo compatible con Linux, es que controladores que llevaban décadas funcionando sin apenas mantenimiento están siendo retirados porque ya no compensa seguir arreglando lo que la IA encuentra en ellos. El kernel en sí no es el problema; lo que falla es la falta de filtro entre lo que una IA encuentra y lo que un humano tiene tiempo de comprobar.
Escrito por Eloy Andrade
