Linux, desbordado por errores hallados con IA: faltan revisores

Encontrar errores en el kernel de Linux se ha vuelto fácil. Corregirlos, no tanto. Según ZDNET, que informó de la situación el 12 de noviembre de 2026, las herramientas de IA generan ya tantos informes de errores y parches que quienes deben revisarlos se están quedando sin fuerzas, y al menos un conocido mantenedor del kernel ha dejado de revisar la mayor parte del código.

Un CVE (Common Vulnerabilities and Exposures) es el identificador público que recibe un fallo de seguridad documentado. Un mantenedor es una persona, voluntaria o asalariada, responsable de una parte del kernel y que decide qué parches se integran. Un revisor (reviewer) lee un parche propuesto y comprueba que es correcto antes de su integración. El kernel de Linux, el núcleo del sistema operativo que funciona desde en teléfonos hasta en supercomputadores, depende de un número reducido de estas personas.

¿Qué tamaño tiene la avalancha de informes de errores en Linux?

Según ZDNET, el equipo de CVE de Linux comunicó una media de 27 CVE al día en 2026, hasta el 2 de noviembre. ZDNET explica este volumen en parte por una regla propia del kernel: en Linux, cualquier error puede ser potencialmente un error de seguridad.

Según Tom's Hardware, que se hace eco de un artículo de Phoronix del 28 de agosto, el kernel se acerca a las 2.000 CVE corregidas por versión, frente a unas 500 durante gran parte de la era Linux 6.x. Una diapositiva de Greg Kroah-Hartman, mantenedor del kernel estable, preparada para la conferencia Kernel Recipes 2026, mostraba cifras por encima de 1.000 con Linux 7.0 y de 1.500 con Linux 7.2. Si la tendencia continúa, Linux 7.3 podría superar las 2.000, según Tom's Hardware.

Tom's Hardware atribuye el aumento sobre todo a personas que rastrean con herramientas de IA un código fuente que ha crecido hasta más de 40 millones de líneas en 35 años, y no a una caída repentina de la calidad del kernel. Esas herramientas llegan a rincones oscuros que los humanos rara vez revisan y a veces encuentran defectos reales: los registros CVE de Linux de este año ya atribuyen al análisis estático asistido por IA hallazgos que luego confirmó Intel Product Security.

El artículo de ZDNET añade una cifra del lado empresarial. El FORGE Lab de Microsoft indicó que su sistema de análisis con IA, MDASH, produjo 59 informes de errores del kernel de Linux en origen (upstream), incluido un fallo de al menos 21 años. Según el laboratorio, convertir esos hallazgos en informes exigió más de cuatro personas-mes porque el esfuerzo humano es el cuello de botella, y describió la búsqueda y la corrección de errores como radicalmente desequilibradas. En el lado de Windows, ZDNET señala que el último Patch Tuesday incluyó 726 CVE, la mayoría procedentes del descubrimiento con IA.

¿Por qué se están quemando los mantenedores del kernel?

La tensión se ve en casos con nombre. Según ZDNET, el 10 de noviembre de 2026 Lorenzo Stoakes, ingeniero de ARM y mantenedor del kernel, dejó de revisar código de las secciones de gestión de memoria, misc, reclaim y Rust, que cubría como revisor. Contribuye al kernel desde 2014. Escribió que, con el volumen actual de series de parches generadas por IA, ya no tiene capacidad para ofrecer revisión general, salvo en las áreas que mantiene él mismo. Añadió que el «slop» generado por IA aparecía al principio de vez en cuando, luego cada semana, luego cada pocos días, y ahora supone aproximadamente la mitad de lo que ve, o más.

Greg Kroah-Hartman, mantenedor del kernel estable, dijo lo mismo en una sesión de preguntas y respuestas en la Open Source Summit Europe, según ZDNET: no hay suficientes personas para revisar el aluvión de parches generados por LLM, y los mantenedores llevan diez años agotados. Su petición fue directa: el kernel necesita más revisores.

Tom's Hardware ofrece un ejemplo medible en redes. En la solicitud de integración de red de Linux 7.3, el mantenedor Jakub Kicinski estimó que entre un tercio y la mitad de los 648 parches de net-next tratados en el ciclo parecían correcciones de baja prioridad, limpiezas o aclaraciones impulsadas por la IA. Escribió que el equipo está completamente desbordado.

La carga de trabajo cambia lo que el kernel conserva. Según Tom's Hardware, el desarrollador Andrew Lunn propuso en abril eliminar casi 28.000 líneas de código de red heredado para hardware de la época ISA y PCMCIA, porque la IA y las herramientas de fuzzing empezaron a encontrar defectos que los mantenedores se sentían obligados a corregir aunque nadie use ese hardware. Linux 7.3 elimina código antiguo de controladores de SGI e IBM, y el controlador del sistema de archivos FreeVxFS se retiró después de que su mantenedor dijera que el viejo código de compatibilidad servía sobre todo de alimento para los verificadores automáticos de errores.

¿Rechaza la comunidad del kernel la IA?

No, y Tom's Hardware es explícito en este punto. El propio Greg Kroah-Hartman ha usado herramientas de fuzzing asistidas por IA y ejecutadas en local para encontrar errores del kernel. La queja se dirige a la producción de IA sin verificar que se entrega a humanos para validarla. Según Tom's Hardware, hace poco vetó los parches generados por LLM en el subsistema staging del kernel, salvo las correcciones de seguridad legítimas, y la guía actualizada del kernel advierte de que los informes generados por IA y enviados sin verificación humana pueden hacer perder tiempo a los mantenedores. El equipo también ha conseguido acceso a varios modelos de frontera para ayudar a revisar parches y filtrar resultados alucinados.

¿Empiezan las correcciones a alcanzar a los informes?

Hay señales tempranas, pero nada concluyente. Según ZDNET, Linus Torvalds escribió en un mensaje de la Linux Kernel Mailing List que gran parte del código nuevo de Linux 7.4-rc2 procedía de correcciones hechas con IA. Dijo que, al menos en el lado de BPF, las correcciones llegan ya más rápido que los nuevos informes, que la mayoría de las demás áreas no han llegado a ese punto y que podría ser una señal de que la marea está cambiando. Su consejo fue no contener la respiración.

Kroah-Hartman es menos optimista. Dijo a ZDNET que el proyecto se está acercando pero aún no está ahí, y se negó a estimar cuándo las correcciones de IA aprobadas por humanos superarán a los informes de errores de IA. Daniel Stenberg, creador del proyecto cURL y crítico contundente de los informes de IA de baja calidad, dijo a ZDNET que cree que su proyecto gestiona bastante bien el aluvión hasta ahora, aunque el volumen sube y baja según quién envíe nuevos hallazgos esa semana.

• 27 CVE al día: la media del equipo de CVE de Linux hasta el 2 de noviembre de 2026, según ZDNET.
• Cerca de 2.000 CVE por versión del kernel, frente a unas 500 durante gran parte de la era 6.x, según Tom's Hardware.
• Entre un tercio y la mitad de 648 parches de red del ciclo de Linux 7.3 se consideraron trabajo de baja prioridad impulsado por IA, según el mantenedor Jakub Kicinski.

¿Qué cambia esto para una empresa?

Para una empresa de España o de América Latina que ejecuta Linux en servidores, contenedores, equipos de red o dispositivos embebidos, la lección práctica es que el número de avisos de seguridad del kernel seguirá subiendo mientras las personas detrás de cada corrección siguen siendo escasas. Un recuento de CVE dice poco del riesgo por sí solo, porque muchas entradas nuevas afectan a controladores poco conocidos; lo que importa es cuáles afectan al hardware y a la configuración del kernel que usted ejecuta de verdad.

De aquí salen tres hábitos. Siga las versiones del kernel estable que entrega su distribución y acorte el tiempo que tarda en aplicarlas. Mantenga un inventario de las funciones y controladores del kernel que activa, para clasificar los avisos con rapidez. Y si su equipo presenta informes de errores con ayuda de la IA, haga que una persona reproduzca cada problema primero, porque la propia guía de los mantenedores dice que los informes sin verificar les hacen perder tiempo. Las empresas que dependen de Linux también pueden ayudar de forma directa financiando o aportando tiempo de revisión, el recurso más escaso según Kroah-Hartman.

Una salvedad: las fuentes no dicen cuándo las correcciones superarán a los informes, y la observación de Torvalds sobre BPF se describe como alentadora pero limitada a esa área. Conviene tratar el periodo actual como una temporada intensa de parches, no como una tendencia consolidada.