Linus Torvalds declaró este domingo en su post semanal a LKML que la lista privada de seguridad del kernel Linux quedó "casi enteramente inmanejable" y culpó del problema a una avalancha de reportes de vulnerabilidades duplicados generados por investigadores que corren las mismas herramientas de IA contra el mismo código. El reclamo acompañó la liberación de Linux 7.1-rc4 y la integración de documentación nueva que formaliza cómo deben manejarse los reportes de bugs asistidos por IA.

¿Cuál es el problema concreto?

El cuello de botella, según Torvalds, está en la combinación de volumen y redundancia: múltiples investigadores descubren independientemente los mismos bugs usando herramientas automatizadas y los presentan por separado en una lista privada donde nadie puede ver qué ya se reportó. Los mantenedores terminan gastando su tiempo en triage de duplicados y redirigiendo a quien reporta a parches que se mergearon semanas antes.

"Los bugs detectados por IA son, prácticamente por definición, no secretos, y tratarlos en una lista privada es una pérdida de tiempo para todos los involucrados", escribió Torvalds en LKML.

Torvalds dirigió a los desarrolladores a la documentación de seguridad del proyecto, que establece que las vulnerabilidades encontradas con herramientas de IA deben tratarse como divulgaciones públicas y enviarse directamente a los mantenedores relevantes, no enrutarse por la lista privada. Los reportes deben ser concisos, en texto plano y con un reproductor verificado.

¿Cuánto creció el flujo de reportes?

En marzo, Willy Tarreau, creador de HAProxy y mantenedor de larga data del kernel Linux estable, comentó en LWN que la lista de seguridad del kernel, que hace dos años recibía cerca de 2 a 3 reportes por semana, ahora recibe 5 a 10 reportes por día. La mayoría son hallazgos sólidos, pero la duplicación entre investigadores que usan herramientas similares colapsó el proceso de triage actual.

¿Qué pide Torvalds a los investigadores?

Torvalds instó a los investigadores a ir más allá de presentar hallazgos en crudo.

"Si realmente quieres agregar valor, lee la documentación, crea también un parche y suma algo real arriba de lo que hizo la IA", escribió. "No seas la persona de drive-by que manda un reporte aleatorio sin entender realmente."

Ese enfoque endosado por Torvalds es exactamente lo que el mantenedor Greg Kroah-Hartman viene haciendo con su sistema "Clanker T1000", una herramienta de búsqueda de bugs corriendo en un Framework Desktop: descubrir el problema, escribir el fix, asumir la responsabilidad del parche y enviarlo de forma pública.

¿Qué dice la política oficial de IA en el kernel?

El proyecto del kernel Linux formalizó el mes pasado su postura más amplia sobre contribuciones asistidas por IA, estableciendo una política de proyecto que permite código generado por IA siempre que los desarrolladores sigan reglas estrictas de divulgación.

Bajo esa política, los agentes de IA no pueden usar el tag legalmente vinculante "Signed-off-by", y los contribuyentes deben usar un nuevo tag "Assisted-by" para transparencia. Cada línea de código generado por IA, y cualquier bug resultante, sigue siendo responsabilidad legal del humano que la envía.

¿Qué implica para el ecosistema de seguridad?

El movimiento ordena la cola pero también cambia el contrato implícito: lo encontrado con automatización pasa a ser información pública, no un secreto industrial que los investigadores puedan guardar para coordinar parches. Eso favorece a los mantenedores con bandwidth para revisar PRs, pero presiona a los equipos comerciales que dependen de la ventana de embargo para preparar mitigaciones internas antes del CVE público. Para distribuciones LatAm que mantienen kernels long-term como Debian o Ubuntu LTS, el cambio probablemente acelera la cadencia de backports, pero también de revisiones de duplicados.