- NVIDIA propone un directorio agents/ y habilidades para que los asistentes de IA sigan las normas del kernel y ayuden con la etiqueta Fixes.
- Boro, herramienta en Rust de código abierto, busca validar parches y facilitar backports, con opciones de IA local o remota.
- El caso XBOW CVE-2026-72018 mostró cómo una IA encontró y explotó un fallo en SMC-D, aunque el criterio humano siguió siendo decisivo.
- La avalancha de informes asistidos por IA tensiona programas de recompensas y obliga a repensar quién paga la revisión.
El kernel Linux lleva décadas como una de las piezas más críticas de la infraestructura digital, pero su mantenimiento siempre ha dependido de un grupo reducido de personas muy especializadas. En los últimos meses, la inteligencia artificial ha dejado de ser una curiosidad en ese terreno para convertirse en un asunto central: NVIDIA ha movido ficha con propuestas y herramientas, la comunidad discute cómo revisar parches con ayuda de agentes y un caso de seguridad ha demostrado que una IA puede encontrar y explotar fallos complejos.
La conversación no va solo de automatizar tareas. También toca quién asume la responsabilidad final cuando un cambio llega al código, cómo se gestionan miles de parches por versión y qué ocurre cuando los informes generados por modelos crecen más rápido que la capacidad humana de revisarlos. En Europa, la Linux Plumbers Conference celebrada en Praga ha servido como escenario para presentar algunas de estas iniciativas.
NVIDIA propone un espacio para agentes de IA en el kernel
Una de las propuestas más comentadas llega de Sasha Levin, desarrollador vinculado a NVIDIA. Su idea es que el proyecto upstream del kernel organice recursos específicos para asistentes de código, como instrucciones, prompts y pequeñas habilidades. El lugar que se baraja inicialmente es un directorio llamado agents/ en la raíz del árbol de código fuente, aunque también se estudia ubicarlo dentro de la documentación existente.
La primera aplicación práctica sería una habilidad capaz de sugerir qué commit anterior debe citarse en la etiqueta Fixes:. Esa etiqueta, habitual en los parches del kernel, conecta una corrección con el cambio que introdujo el problema. Identificarla bien ahorra trabajo repetitivo y mejora la trazabilidad, pero la propuesta no implica que un modelo vaya a acertar siempre ni que sus sugerencias se acepten sin revisión.
Conviene subrayar que no se trata de una función ya incorporada. Según las informaciones difundidas, la iniciativa sigue en fase de discusión y no hay una decisión cerrada sobre la ubicación final ni sobre qué recursos se incluirían. Levin ya ha participado en otras ideas relacionadas con IA para el kernel, como AGENTS.md, la resolución de conflictos de merge o la identificación de parches para backport, pero eso no convierte esta propuesta en un cambio aprobado.
Boro, la apuesta de NVIDIA por validar parches con IA
En paralelo, NVIDIA trabaja en Boro, una herramienta de línea de comandos escrita en Rust que usa inteligencia artificial para asistir en tareas de mantenimiento del kernel. El proyecto está liderado por Andrea Righi y se presentó durante la Linux Plumbers Conference 2026, celebrada en Praga entre el 5 y el 7 de octubre. Su foco no es escribir software desde cero, sino validar parches, compilarlos, arrancarlos y probarlos en distintos escenarios.
Uno de los usos que más interés despierta es el backporting, es decir, llevar un cambio pensado para una versión reciente a una versión anterior del kernel. Ese proceso exige comprobar compatibilidades y condiciones del código de destino, algo que puede consumir mucho tiempo a los mantenedores. Boro aspira a facilitar esa validación, sin que la información disponible indique que sustituya el criterio de los desarrolladores.
La herramienta admite ejecución local con IA, pensada para quien tiene capacidad de cómputo suficiente, y también servidores remotos compatibles con OpenAI. Entre los backends mencionados aparecen Claude, OpenCode y Codex. Boro se distribuye con licencia Apache 2.0 y su código puede consultarse en el repositorio NVIDIA/boro de GitHub. También figura como objetivo futuro detectar fallos en módulos out-of-tree, aunque eso todavía no es una capacidad confirmada.
Sashiko y la revisión automática: ayuda, no sustituto
Sashiko se ha discutido en la lista de correo del kernel como una forma de revisar cambios con agentes que leen parches, buscan patrones peligrosos y piden contexto cuando algo no cuadra. La idea responde a un problema de escala: cada versión trae miles de modificaciones y los revisores humanos no dan abasto. La herramienta no firma aprobaciones ni sustituye al mantenedor, pero puede ordenar la cola por riesgo y explicar por qué marca cada parche.
El momento no es casual. El 1 de octubre, el mantenedor Greg Kroah-Hartman describió una avalancha de informes ayudados por modelos, con muchas falsas alarmas mezcladas con avisos válidos. En este contexto, una herramienta que explique sus hallazgos vale más que otra que genere candidatos en masa. Para un lector no técnico, la diferencia es parecida a la de un corrector que no solo subraya faltas, sino que pregunta al autor por qué cambió una frase delicada.
El caso XBOW: una IA encontró un fallo y llegó a root
A finales de septiembre de 2026, la investigación de XBOW puso sobre la mesa el otro lado de la moneda. Un sistema autónomo encontró y explotó un fallo que había pasado desapercibido para revisores humanos. El problema, registrado como CVE-2026-72018, vivía en la pila SMC-D, un protocolo de IBM para comunicar máquinas virtuales por memoria compartida. Durante años exigió hardware específico de mainframe, pero con la abstracción DIBS y el controlador dibs_loopback empezó a ejecutarse en equipos x86 por loopback.
El fallo permitía a un usuario local con capacidades de red escalar a root mediante una escritura de apenas 16 bytes a cero. La clave estaba en que el kernel multiplicaba tamaño por índice para calcular un desplazamiento sin comprobar rangos, lo que podía empujar una copia fuera del búfer legítimo de 16384 bytes y escribir una cabecera de 32 bytes, 16 de ellos ceros. No hacía falta una cadena compleja ni fugas de memoria: bastaba colocar los ceros donde dolía, en la estructura cred que guarda los identificadores de usuario.
XBOW demostró el camino completo con interceptación de tráfico loopback mediante NFQUEUE, falsificación de mensajes de handshake y recálculo de sumas de comprobación. Todo ello requiere CAP_NET_ADMIN, un permiso que aparece en contenedores y demonios de red, así que el modelo de amenaza resulta realista. En Ubuntu 24.04 con mitigaciones desactivadas, el prototipo logró root en 22 de 100 arranques. El fallo se reportó el 19 de junio, el parche se aprobó el 7 de julio y el CVE se publicó el 17 de agosto.
La investigación también deja una lección sobre el papel humano. XBOW reconoce tres momentos en los que una persona recondujo el trabajo: cuando el índice a cero parecía un callejón sin salida, cuando el agente confundía modelos de escritura y cuando se empeñaba en convertir los ceros en algo más potente. Los modelos leen código sin cansarse, pero desarrollan sesgos cuando el contexto crece. La respuesta que propone XBOW es repartir el trabajo entre varios agentes con contextos acotados en lugar de cargar una campaña larga sobre uno solo.
La saturación de informes generados por IA
El caso XBOW no flota en el vacío. Durante 2026, varios programas de recompensas por vulnerabilidades han tenido que reaccionar al aumento de informes asistidos por inteligencia artificial. En enero, el proyecto curl suspendió su programa de recompensas. En marzo, Google decidió que su programa para software de código abierto no aceptaría informes generados por IA, después de encontrar invenciones sobre cómo explotar fallos y descripciones de defectos de poco impacto real.
El 3 de abril llegó otro movimiento relevante: HackerOne, que administra el Internet Bug Bounty, suspendió los nuevos envíos. Desde 2012 el programa había repartido 1,5 millones de dólares, con un 80 por ciento destinado a descubrir vulnerabilidades nuevas y un 20 por ciento a ayudar a corregirlas. Encontrar fallos se ha vuelto más barato; repararlos, no. Quien mantiene un proyecto abierto suele ser una persona o un grupo pequeño de voluntarios, y cada informe hay que leerlo, reproducirlo y valorarlo.
Como respuesta, Google, Anthropic, AWS, Microsoft, OpenAI, la Linux Foundation, Alpha-Omega y la Open Source Security Foundation han reunido 12,5 millones de dólares para ayudar a los mantenedores a gestionar el volumen con herramientas de IA. Greg Kroah-Hartman, del kernel de Linux, ha advertido de que la financiación por sí sola no resuelve el problema que esas herramientas están creando en los equipos de seguridad. La pregunta de fondo sigue abierta: si los fallos se encuentran por decenas, quizá el dinero deba ir también a quien escribe las correcciones.
Qué implica para administradores y desarrolladores en Europa
Para quien administra servidores o contenedores, el calendario ayuda a calibrar la urgencia sin alarmismo. Si el kernel se actualizó después del verano, la corrección de CVE-2026-72018 ya debería estar aplicada en las distribuciones habituales. No hay indicios de explotación masiva en este caso concreto, pero la ventana entre junio y agosto existió. En flotas europeas, conviene inventariar versiones, revisar si hay módulos SMC cargados y recortar CAP_NET_ADMIN donde sobre.
La rutina no es distinta de la que ya se sigue con otros parches críticos. Comprobar la versión con uname -r, priorizar anfitriones con servicios expuestos o contenedores privilegiados, programar reinicios y verificar que el sistema ha arrancado con el kernel corregido. Un parche en disco no protege hasta que la máquina reinicia. En nubes públicas, las imágenes recientes suelen incorporar la corrección, así que las instancias nuevas arrancan cubiertas.
En el plano del desarrollo, la discusión europea presentada en Praga apunta a una convivencia incómoda pero necesaria. Las herramientas de IA pueden revisar parches, sugerir etiquetas Fixes, ordenar riesgos y probar backports, pero la decisión final sigue estando en manos humanas. La diferencia entre defensa y ataque no está tanto en el modelo como en quién formula la pregunta, con qué permisos actúa y qué controles se aplican después.
El kernel Linux afronta así una etapa en la que la inteligencia artificial entra en su mantenimiento por varias puertas: propuestas organizativas como la de Sasha Levin, utilidades como Boro, revisores como Sashiko y casos de seguridad como el de XBOW. Ninguna de esas piezas es una bala de plata. La clave será integrar la automatización sin perder trazabilidad, revisión humana y responsabilidad. Si la comunidad consigue que los agentes expliquen sus motivos, enlacen pruebas y acepten un no por respuesta, el kernel podría ganar capacidad de respuesta. Si, por el contrario, se impone una marea de candidatos sin contexto, los fallos importantes seguirán esperando turno.