Linux se acerca a 2.000 CVE por versión, según un adelanto de datos

Según un adelanto de una presentación de Greg Kroah-Hartman, el kernel de Linux pasó de registrar cerca de 500 CVE corregidos por versión a superar los 1.000 desde Linux 7.0, mientras modelos de IA examinan sus cerca de 40 millones de líneas de código. El desarrollador anticipa que Linux 7.3 podría rebasar los 2.000 reportes, aunque la mayoría correspondería a fallos de menor prioridad en controladores antiguos.
***

• Los modelos de IA y LLM pueden aumentar la detección de vulnerabilidades en el código del kernel de Linux.
• Según los datos anticipados, los reportes pasaron de un promedio cercano a 500 por versión a más de 1.000 desde Linux 7.0, con Linux 7.2 por encima de 1.500.
• Greg Kroah-Hartman presentará estos datos en Kernel Recipes 2026, evento previsto del 21 al 23 de septiembre en París.

El kernel de Linux podría aproximarse a una cifra inédita de vulnerabilidades corregidas por versión, de acuerdo con un adelanto de datos atribuido al desarrollador Greg Kroah-Hartman. La presentación relaciona el aumento de hallazgos con la expansión de herramientas de inteligencia artificial capaces de revisar grandes volúmenes de código. El sistema operativo, cuyo árbol de código fuente ronda los 40 millones de líneas, habría pasado de registrar habitualmente cerca de 500 CVE por versión a superar los 1.000 en las versiones más recientes. La tendencia podría llevar a Linux 7.3 por encima de los 2.000 reportes.

La información aparece antes de una próxima presentación de Kroah-Hartman en Kernel Recipes 2026, un evento programado del 21 al 23 de septiembre en París, Francia. Phoronix informó que la diapositiva reúne los CVE asociados con versiones que van desde Linux 6.9 hasta Linux 7.2 y muestra un salto progresivo a medida que los modelos de IA y los grandes modelos de lenguaje examinan el proyecto.

El archivo oficial del proyecto identifica a Linux 7.2 como la rama principal vigente y registra la versión estable 7.2.2 al 28 de agosto de 2026. Esto sitúa la referencia a Linux 7.3 como una proyección, no como una versión ya publicada.

Una curva de vulnerabilidades en ascenso

Los datos presentados por Kroah-Hartman reflejan una diferencia entre las ramas anteriores y las versiones más nuevas del kernel. Desde Linux 6.9 hasta Linux 6.19, el promedio se ubicaba alrededor de 500 CVE corregidos por versión, mientras que el registro comenzó a superar los 1.000 por versión a partir de Linux 7.0. La comparación no describe necesariamente un deterioro repentino del software, sino que también puede reflejar una capacidad de detección mucho mayor.

El crecimiento se aceleró todavía más con Linux 7.2, versión que habría superado los 1.500 CVE corregidos, según la diapositiva anticipada por el desarrollador. Si los modelos generativos continúan identificando fallos al ritmo señalado, el umbral de 2.000 podría alcanzarse con Linux 7.3, una posibilidad que convierte la próxima edición del kernel en un punto de atención para los responsables de seguridad.

En este contexto, la cifra de CVE funciona como un indicador de vulnerabilidades documentadas y corregidas, no como una medida directa de ataques exitosos contra usuarios. Además, un CVE es un registro de una vulnerabilidad divulgada: su existencia no implica que todos los sistemas estén expuestos ni que el fallo se esté explotando activamente.

La cantidad también puede aumentar porque las herramientas encuentran problemas que antes permanecían sin clasificar, incluidos defectos localizados en componentes poco utilizados o en código que llevaba años dentro del proyecto. Por ello, el número bruto debe analizarse junto con la prioridad, el componente afectado y la posibilidad real de explotación.

La expansión de estos reportes plantea una dificultad de interpretación para administradores, distribuidores y desarrolladores. Un volumen mayor puede reflejar un ecosistema más expuesto, pero también un proceso de revisión más exhaustivo, por lo que no permite concluir por sí solo que Linux sea menos seguro que antes.

El papel de la inteligencia artificial

Los modelos de IA y los LLM pueden recorrer bases de código extensas en busca de patrones asociados con errores de memoria, validaciones incompletas u otras condiciones potencialmente inseguras. En un proyecto del tamaño del kernel de Linux, esa capacidad permite revisar zonas que difícilmente recibirían el mismo nivel de atención mediante inspecciones manuales, especialmente cuando existen miles de controladores y subsistemas con distintos niveles de actividad.

La información divulgada describe un aumento de modelos que analizan el código del kernel y generan más hallazgos susceptibles de convertirse en CVE. Sin embargo, detectar un patrón sospechoso no equivale por sí solo a demostrar una vulnerabilidad crítica, porque cada reporte necesita validación técnica, asignación de severidad y, cuando corresponde, una corrección integrada al proyecto.

El aumento de alertas puede beneficiar la seguridad si ayuda a retirar defectos antiguos antes de que alguien los explote. También puede elevar los costos de clasificación y mantenimiento, ya que los equipos deben separar los problemas relevantes de los hallazgos de bajo impacto, revisar falsos positivos y decidir cuáles correcciones deben llegar a las ramas sostenidas por las distribuciones.

Esta tensión explica por qué un récord de CVE no permite concluir automáticamente que Linux sea menos seguro que antes. Una mayor visibilidad de los fallos puede coexistir con una respuesta más rápida y con la eliminación de componentes problemáticos, aunque el flujo de reportes obligue a los mantenedores a rediseñar sus prioridades y herramientas de seguimiento.

La mayoría tendría impacto limitado

Kroah-Hartman señaló que, afortunadamente, la mayoría de los hallazgos suelen corresponder a vulnerabilidades de menor prioridad. Muchos aparecen en controladores antiguos, poco conocidos o escasamente utilizados, de modo que su impacto práctico suele ser limitado frente a un defecto que afectara las funciones centrales del kernel o una configuración ampliamente desplegada.

Esta distinción resulta importante para quienes reciben boletines de seguridad con cientos o miles de entradas. La presencia de un CVE no significa que todos los equipos Linux estén expuestos en las mismas condiciones, porque la relevancia depende del controlador instalado, del hardware utilizado, de las funciones habilitadas y de la versión concreta que administra cada organización.

El hecho de que numerosos reportes correspondan a código antiguo u oscuro no elimina la necesidad de corregirlos, pero sí cambia la urgencia operativa. Los responsables de sistemas deben priorizar las vulnerabilidades que afectan componentes activos y accesibles, mientras los mantenedores evalúan si una corrección, una mitigación o la eliminación del código ofrece la respuesta más adecuada.

En consecuencia, la futura marca de 2.000 CVE por versión tendría un significado principalmente operativo y estadístico. Sería una señal de que la revisión automatizada amplió el perímetro de análisis, pero no una prueba suficiente para afirmar que el kernel enfrenta 2.000 amenazas críticas en cada lanzamiento.

Código obsoleto bajo revisión

El exceso de informes de errores y seguridad coincide con la decisión adoptada durante este año de eliminar una cantidad importante de código obsoleto del kernel. No obstante, la coincidencia temporal no demuestra por sí sola que el aumento de CVE haya causado esa decisión. Retirar componentes antiguos puede responder a consideraciones de mantenimiento, compatibilidad y seguridad evaluadas por separado.

Retirar código antiguo puede reducir el número de rutas que deben revisarse y mantener, aunque el proceso requiere cautela por la diversidad de hardware y distribuciones que dependen de Linux. Un controlador poco usado no es necesariamente irrelevante para todos los usuarios, por lo que las decisiones de eliminación deben considerar compatibilidad, reemplazos disponibles y la evidencia sobre su uso real.

La IA, por tanto, podría no solo acelerar la identificación de defectos, sino también presionar al proyecto para simplificar su base tecnológica. Esa simplificación puede facilitar futuras auditorías y disminuir la carga para los mantenedores, pero también abre discusiones sobre soporte, preservación de funciones y el equilibrio entre un kernel más manejable y uno capaz de cubrir hardware muy diverso.

El próximo paso será observar cómo se comporta Linux 7.3 y qué criterios aplica la comunidad para ordenar los nuevos hallazgos. La presentación de Kernel Recipes 2026 ofrecerá más contexto sobre la evolución de los CVE por versión, mientras el desafío central seguirá siendo convertir una mayor capacidad de detección en correcciones útiles y prioridades claras.

Imagen original de DiarioBitcoin, creada con inteligencia artificial, de uso libre, licenciada bajo Dominio Público.

Este artículo fue escrito por un redactor de contenido de IA y revisado por un editor humano para garantizar calidad y precisión.

ADVERTENCIA: DiarioBitcoin ofrece contenido informativo y educativo sobre diversos temas, incluyendo criptomonedas, IA, tecnología y regulaciones. No brindamos asesoramiento financiero. Las inversiones en criptoactivos son de alto riesgo y pueden no ser adecuadas para todos. Investigue, consulte a un experto y verifique la legislación aplicable antes de invertir. Podría perder todo su capital.

Suscríbete a nuestro boletín