CVE-2025-38389

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm/i915/gt: Se corrige el error de línea de tiempo retenida en la asignación de VMA. CI ha informado esporádicamente del siguiente error cuando una prueba desvincula el controlador i915 en una plataforma de envío de anillo: <4> [239.330153] ------------[ cut here ]------------ <4> [239.330166] i915 0000:00:02.0: [drm] drm_WARN_ON(dev_priv->mm.shrink_count) <4> [239.330196] WARNING: CPU: 1 PID: 18570 at drivers/gpu/drm/i915/i915_gem.c:1309 i915_gem_cleanup_early+0x13e/0x150 [i915] ... <4> [239.330640] RIP: 0010:i915_gem_cleanup_early+0x13e/0x150 [i915] ... <4> [239.330942] Call Trace: <4> [239.330944] <4> [239.330949] i915_driver_late_release+0x2b/0xa0 [i915] <4> [239.331202] i915_driver_release+0x86/0xa0 [i915] <4> [239.331482] devm_drm_dev_init_release+0x61/0x90 <4> [239.331494] devm_action_release+0x15/0x30 <4> [239.331504] release_nodes+0x3d/0x120 <4> [239.331517] devres_release_all+0x96/0xd0 <4> [239.331533] device_unbind_cleanup+0x12/0x80 <4> [239.331543] device_release_driver_internal+0x23a/0x280 <4> [239.331550] ? bus_find_device+0xa5/0xe0 <4> [239.331563] device_driver_detach+0x14/0x20 ... <4> [357.719679] ---[ end trace 0000000000000000 ]--- If the test also unloads the i915 module then that's followed with: <3> [357.787478] ============================================================================= <3> [357.788006] BUG i915_vma (Tainted: G U W N ): Objects remaining on __kmem_cache_shutdown() <3> [357.788031] ----------------------------------------------------------------------------- <3> [357.788204] Object 0xffff888109e7f480 @offset=29824 <3> [357.788670] Allocated in i915_vma_instance+0xee/0xc10 [i915] age=292729 cpu=4 pid=2244 <4> [357.788994] i915_vma_instance+0xee/0xc10 [i915] <4> [357.789290] init_status_page+0x7b/0x420 [i915] <4> [357.789532] intel_engines_init+0x1d8/0x980 [i915] <4> [357.789772] intel_gt_init+0x175/0x450 [i915] <4> ---truncado--- Un análisis más detallado del historial de resultados de CI ha revelado una dependencia del error en algunas pruebas IGT, a saber: - igt@api_intel_allocator@fork-simple-stress-signal, - igt@api_intel_allocator@two-level-inception-interruptible, - igt@gem_linear_blits@interruptible, - igt@prime_mmap_coherency@ioctl-errors, que activan el problema de forma invisible y se muestran con el primer intento de desvinculación del controlador. Todas las pruebas anteriores realizan acciones que se interrumpen activamente con señales. Una depuración posterior ha permitido limitar este alcance a DRM_IOCTL_I915_GEM_EXECBUFFER2 y ring_context_alloc(), específicos para el envío de anillos. Si la ejecución es correcta, se supone que esa función, o sus execlists o equivalentes de envío de GuC, se llamará solo una vez por motor de contexto GEM, seguido de la activación de un indicador que impide que se vuelva a llamar. Se espera que la función corrija sus errores internos por sí misma, por lo que puede volver a llamarse de forma segura después de devolver un error. En caso de envío de anillo, la función primero obtiene una referencia a la línea de tiempo heredada del motor y luego asigna un VMA. Si la asignación del VMA falla, por ejemplo, cuando i915_vma_instance() llamado desde dentro se interrumpe con una señal, entonces ring_context_alloc() falla, dejando la línea de tiempo referenciada. En la siguiente IOCTL I915_GEM_EXECBUFFER2, se obtiene otra referencia a la línea de tiempo, y solo esta última se coloca al completarse correctamente. Como consecuencia, la línea de tiempo heredada, con el objeto VMA de su página de estado del motor subyacente, aún se mantiene y no se libera al desvincular el controlador. Obtenga la línea de tiempo heredada solo después de la asignación exitosa del VMA del motor de contexto. v2: Agregar una nota sobre otros métodos de envío (Krzysztof Karas): Tanto los execlists como el envío GuC usan lrc_alloc(), que parec