Linus Torvalds ha cerrado un fallo del controlador gráfico Xe de Linux que provocaba que una máquina con una GPU Intel Battlemage G21 de 16 GB pudiera terminar con el gestor gráfico reiniciándose. El detalle más llamativo no está solo en que la corrección terminara reducida a un cambio de redondeo, sino en el proceso: Torvalds utilizó una IA para instrumentar el kernel y analizar resultados, pero siguió investigando cuando el modelo consideró varias veces que el problema era imposible de resolver. El commit oficial 818bebeb63dd6bf5f4e07e145f6cdbace520a34c fue firmado por Torvalds el 20 de agosto de 2026.
Las claves de este fallo de Linux en 30 segundos
- El problema estaba en el controlador gráfico Xe, no en el antiguo i915.
- Afectaba a una configuración concreta de Intel Battlemage G21 con 16 GB de VRAM.
- La investigación necesitó 24 parches de depuración y 18 arranques del kernel.
- La corrección cambia un
round_up()por unround_down()para no entregar memoria CCS al asignador de VRAM. - La IA ayudó con instrumentación, análisis y el mensaje del commit, pero Torvalds rechazó su conclusión de que el fallo no tenía solución.
El error estaba en cómo Linux calculaba la VRAM disponible
La historia tiene además una corrección importante respecto a algunas versiones que han circulado sobre el problema. El código afectado pertenece al driver Xe de Intel, en drivers/gpu/drm/xe/xe_vram.c. No se trata de un fallo del controlador i915 ni de un archivo denominado i915_flat_ccs.c.
El origen estaba en get_flat_ccs_offset(), una función que calcula dónde empieza el almacenamiento Flat CCS, relacionado con la compresión de memoria de las GPU Intel. El cálculo obtenía una dirección desde los registros del hardware, la ajustaba según el número de nodos L3 habilitados y después utilizaba ese resultado para determinar qué parte de la VRAM podía entregar el sistema al asignador de memoria.
El problema era especialmente delicado porque el código utilizaba round_up(offset, SZ_128K). En otras palabras, redondeaba hacia arriba el límite que indicaba hasta dónde podía considerarse utilizable la VRAM.
En el caso concreto de una Battlemage G21 con 16 GiB, ese redondeo hacía que una pequeña parte del almacenamiento reservado para CCS terminara apareciendo como memoria disponible. El propio commit de Torvalds documenta un caso en el que la dirección real era 0x3fafff800 y el redondeo la llevaba hasta 0x3fb000000. El resultado dejaba los últimos 2 KiB de una página dentro del área de CCS incluida por error en el conjunto de memoria que podía asignarse.
Eso explica por qué el fallo podía ser tan difícil de localizar. No hacía falta que el sistema intentara acceder directamente a una dirección claramente inválida. El problema consistía en que dos usos diferentes de la memoria acababan solapándose: el asignador de VRAM podía considerar disponible una zona que el hardware de compresión seguía utilizando.
El resultado podía ser la corrupción de estructuras utilizadas por la GPU. En la máquina afectada, el síntoma visible terminaba siendo un fallo del entorno gráfico y nuevos reinicios del gestor de pantalla.
24 parches, 18 arranques y una IA que quería abandonar
La parte más llamativa aparece en el propio mensaje del commit. Torvalds explica que la investigación requirió 24 parches de depuración y 18 arranques del kernel antes de aislar el problema. La IA fue utilizada como ayuda durante ese proceso y se encargó de buena parte de la instrumentación y del análisis de los resultados.
Pero el modelo también llegó repetidamente a la conclusión de que el problema era imposible o irresoluble. Torvalds decidió continuar en lugar de aceptar ese diagnóstico. Según explica en el commit, la herramienta sí siguió generando código de depuración y analizando los datos cuando se le insistía, y finalmente el desarrollador le atribuyó suficiente trabajo como para permitirle redactar el mensaje del propio commit.
Ese detalle resulta más interesante que la simple anécdota de que Linus Torvalds haya utilizado IA. El episodio muestra una división bastante concreta entre generar trabajo técnico y decidir cuándo una hipótesis está realmente demostrada.
La IA podía añadir instrumentación, proponer modificaciones, analizar salidas y repetir ciclos de prueba. La decisión de no aceptar que el problema era «imposible» siguió siendo humana. Y el hecho de que el modelo llegara a una conclusión negativa durante la investigación no significaba que esa conclusión fuera una propiedad del sistema que estaba depurando.
La solución fue pequeña, pero el diagnóstico no lo era
El parche final modifica precisamente ese cálculo. En lugar de redondear el límite hacia arriba a 128 KiB, el código pasa a redondearlo hacia abajo a una página de 4 KiB. El propio comentario añadido al código explica el motivo: todo lo que queda por debajo del desplazamiento calculado se entrega al asignador de VRAM, por lo que el límite tiene que representar el primer punto que pertenece al almacenamiento de compresión y no puede desplazarse hacia una zona que todavía pertenece a CCS.
El cambio conceptual puede resumirse así:
Antes:
offset = round_up(offset, SZ_128K);
Después:
offset = round_down(offset, SZ_4K);La diferencia entre ambas operaciones parece pequeña en código, pero tiene consecuencias completamente distintas cuando el valor calculado representa una frontera de memoria. Redondear hacia arriba puede incluir memoria que no debería estar disponible. Redondear hacia abajo mantiene el límite dentro de la región que el sistema puede utilizar con seguridad.
El parche no se limita a cambiar esa llamada. También modifica la comprobación que debía detectar una separación incorrecta entre las regiones de memoria. El commit explica que la comprobación anterior no servía para detectar correctamente este escenario y la sustituye por una condición capaz de identificar la situación que realmente interesa.
Hay otro dato que ayuda a entender por qué este caso no encaja bien con la idea de un simple «bug de una línea». La corrección final sí puede describirse de esa manera, pero llegar hasta esa línea exigió observar el comportamiento real del sistema, introducir instrumentación, reiniciar el kernel repetidamente y comparar los resultados. En ingeniería de bajo nivel, reducir el tamaño del parche no equivale a reducir la dificultad del diagnóstico.
Un problema concreto del driver Xe, no una vulnerabilidad de Linux
También conviene evitar otra exageración presente en algunas versiones del relato. El commit oficial no presenta este problema como una vulnerabilidad de seguridad ni como un exploit. Se trata de un fallo del controlador gráfico que podía hacer que memoria reservada para la compresión apareciera como VRAM disponible. El impacto descrito está relacionado con la estabilidad y la corrupción de memoria utilizada por la GPU.
Eso no impide que los errores de gestión de memoria sean relevantes desde el punto de vista de seguridad en otros escenarios, pero convertir este caso concreto en una vulnerabilidad explotable sin evidencia adicional iría más allá de lo que demuestra el parche.
La corrección, además, no aparece aislada del proceso habitual de mantenimiento del kernel. El commit incluye una referencia Fixes al cambio que introdujo el cálculo problemático y una etiqueta Cc: [email protected], utilizada para solicitar que la corrección llegue también a las ramas estables afectadas.
La documentación oficial del kernel explica precisamente que las ramas estables reciben correcciones de problemas y que los parches destinados a corregir errores se incorporan durante el proceso de estabilización.
La historia deja así una conclusión más útil que «la IA se equivocó». Un modelo puede participar en una investigación de kernel de altísima complejidad y ahorrar trabajo mecánico, pero una salida aparentemente segura sigue siendo una hipótesis que debe contrastarse con el código, el hardware y las pruebas. En este caso, el upstream de Linux conserva el rastro completo: 24 parches de depuración, 18 arranques, una dirección de memoria que reveló el solapamiento y, finalmente, un cambio muy pequeño que corrigió la frontera entre la VRAM utilizable y el almacenamiento CCS.
