fkie_cve-2025-38389
Vulnerability from fkie_nvd
Published
2025-07-25 13:15
Modified
2025-07-25 15:29
Severity ?
Summary
In the Linux kernel, the following vulnerability has been resolved: drm/i915/gt: Fix timeline left held on VMA alloc error The following error has been reported sporadically by CI when a test unbinds the i915 driver on a ring submission platform: <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] <TASK> <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> [357.790014] i915_gem_init+0x113/0x340 [i915] <4> [357.790281] i915_driver_probe+0x847/0xed0 [i915] <4> [357.790504] i915_pci_probe+0xe6/0x220 [i915] ... Closer analysis of CI results history has revealed a dependency of the error on a few IGT tests, namely: - 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, which invisibly trigger the issue, then exhibited with first driver unbind attempt. All of the above tests perform actions which are actively interrupted with signals. Further debugging has allowed to narrow that scope down to DRM_IOCTL_I915_GEM_EXECBUFFER2, and ring_context_alloc(), specific to ring submission, in particular. If successful then that function, or its execlists or GuC submission equivalent, is supposed to be called only once per GEM context engine, followed by raise of a flag that prevents the function from being called again. The function is expected to unwind its internal errors itself, so it may be safely called once more after it returns an error. In case of ring submission, the function first gets a reference to the engine's legacy timeline and then allocates a VMA. If the VMA allocation fails, e.g. when i915_vma_instance() called from inside is interrupted with a signal, then ring_context_alloc() fails, leaving the timeline held referenced. On next I915_GEM_EXECBUFFER2 IOCTL, another reference to the timeline is got, and only that last one is put on successful completion. As a consequence, the legacy timeline, with its underlying engine status page's VMA object, is still held and not released on driver unbind. Get the legacy timeline only after successful allocation of the context engine's VMA. v2: Add a note on other submission methods (Krzysztof Karas): Both execlists and GuC submission use lrc_alloc() which seems free from a similar issue. (cherry picked from commit cc43422b3cc79eacff4c5a8ba0d224688ca9dd4f)
Impacted products
Vendor Product Version



{
  "cveTags": [],
  "descriptions": [
    {
      "lang": "en",
      "value": "In the Linux kernel, the following vulnerability has been resolved:\n\ndrm/i915/gt: Fix timeline left held on VMA alloc error\n\nThe following error has been reported sporadically by CI when a test\nunbinds the i915 driver on a ring submission platform:\n\n\u003c4\u003e [239.330153] ------------[ cut here ]------------\n\u003c4\u003e [239.330166] i915 0000:00:02.0: [drm] drm_WARN_ON(dev_priv-\u003emm.shrink_count)\n\u003c4\u003e [239.330196] WARNING: CPU: 1 PID: 18570 at drivers/gpu/drm/i915/i915_gem.c:1309 i915_gem_cleanup_early+0x13e/0x150 [i915]\n...\n\u003c4\u003e [239.330640] RIP: 0010:i915_gem_cleanup_early+0x13e/0x150 [i915]\n...\n\u003c4\u003e [239.330942] Call Trace:\n\u003c4\u003e [239.330944]  \u003cTASK\u003e\n\u003c4\u003e [239.330949]  i915_driver_late_release+0x2b/0xa0 [i915]\n\u003c4\u003e [239.331202]  i915_driver_release+0x86/0xa0 [i915]\n\u003c4\u003e [239.331482]  devm_drm_dev_init_release+0x61/0x90\n\u003c4\u003e [239.331494]  devm_action_release+0x15/0x30\n\u003c4\u003e [239.331504]  release_nodes+0x3d/0x120\n\u003c4\u003e [239.331517]  devres_release_all+0x96/0xd0\n\u003c4\u003e [239.331533]  device_unbind_cleanup+0x12/0x80\n\u003c4\u003e [239.331543]  device_release_driver_internal+0x23a/0x280\n\u003c4\u003e [239.331550]  ? bus_find_device+0xa5/0xe0\n\u003c4\u003e [239.331563]  device_driver_detach+0x14/0x20\n...\n\u003c4\u003e [357.719679] ---[ end trace 0000000000000000 ]---\n\nIf the test also unloads the i915 module then that\u0027s followed with:\n\n\u003c3\u003e [357.787478] =============================================================================\n\u003c3\u003e [357.788006] BUG i915_vma (Tainted: G     U  W        N ): Objects remaining on __kmem_cache_shutdown()\n\u003c3\u003e [357.788031] -----------------------------------------------------------------------------\n\u003c3\u003e [357.788204] Object 0xffff888109e7f480 @offset=29824\n\u003c3\u003e [357.788670] Allocated in i915_vma_instance+0xee/0xc10 [i915] age=292729 cpu=4 pid=2244\n\u003c4\u003e [357.788994]  i915_vma_instance+0xee/0xc10 [i915]\n\u003c4\u003e [357.789290]  init_status_page+0x7b/0x420 [i915]\n\u003c4\u003e [357.789532]  intel_engines_init+0x1d8/0x980 [i915]\n\u003c4\u003e [357.789772]  intel_gt_init+0x175/0x450 [i915]\n\u003c4\u003e [357.790014]  i915_gem_init+0x113/0x340 [i915]\n\u003c4\u003e [357.790281]  i915_driver_probe+0x847/0xed0 [i915]\n\u003c4\u003e [357.790504]  i915_pci_probe+0xe6/0x220 [i915]\n...\n\nCloser analysis of CI results history has revealed a dependency of the\nerror on a few IGT tests, namely:\n- igt@api_intel_allocator@fork-simple-stress-signal,\n- igt@api_intel_allocator@two-level-inception-interruptible,\n- igt@gem_linear_blits@interruptible,\n- igt@prime_mmap_coherency@ioctl-errors,\nwhich invisibly trigger the issue, then exhibited with first driver unbind\nattempt.\n\nAll of the above tests perform actions which are actively interrupted with\nsignals.  Further debugging has allowed to narrow that scope down to\nDRM_IOCTL_I915_GEM_EXECBUFFER2, and ring_context_alloc(), specific to ring\nsubmission, in particular.\n\nIf successful then that function, or its execlists or GuC submission\nequivalent, is supposed to be called only once per GEM context engine,\nfollowed by raise of a flag that prevents the function from being called\nagain.  The function is expected to unwind its internal errors itself, so\nit may be safely called once more after it returns an error.\n\nIn case of ring submission, the function first gets a reference to the\nengine\u0027s legacy timeline and then allocates a VMA.  If the VMA allocation\nfails, e.g. when i915_vma_instance() called from inside is interrupted\nwith a signal, then ring_context_alloc() fails, leaving the timeline held\nreferenced.  On next I915_GEM_EXECBUFFER2 IOCTL, another reference to the\ntimeline is got, and only that last one is put on successful completion.\nAs a consequence, the legacy timeline, with its underlying engine status\npage\u0027s VMA object, is still held and not released on driver unbind.\n\nGet the legacy timeline only after successful allocation of the context\nengine\u0027s VMA.\n\nv2: Add a note on other submission methods (Krzysztof Karas):\n    Both execlists and GuC submission use lrc_alloc() which seems free\n    from a similar issue.\n\n(cherry picked from commit cc43422b3cc79eacff4c5a8ba0d224688ca9dd4f)"
    },
    {
      "lang": "es",
      "value": "En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm/i915/gt: Se corrige el error de l\u00ednea de tiempo retenida en la asignaci\u00f3n de VMA. CI ha informado espor\u00e1dicamente del siguiente error cuando una prueba desvincula el controlador i915 en una plataforma de env\u00edo de anillo: \u0026lt;4\u0026gt; [239.330153] ------------[ cut here ]------------ \u0026lt;4\u0026gt; [239.330166] i915 0000:00:02.0: [drm] drm_WARN_ON(dev_priv-\u0026gt;mm.shrink_count) \u0026lt;4\u0026gt; [239.330196] WARNING: CPU: 1 PID: 18570 at drivers/gpu/drm/i915/i915_gem.c:1309 i915_gem_cleanup_early+0x13e/0x150 [i915] ... \u0026lt;4\u0026gt; [239.330640] RIP: 0010:i915_gem_cleanup_early+0x13e/0x150 [i915] ... \u0026lt;4\u0026gt; [239.330942] Call Trace: \u0026lt;4\u0026gt; [239.330944]  \u0026lt;4\u0026gt; [239.330949] i915_driver_late_release+0x2b/0xa0 [i915] \u0026lt;4\u0026gt; [239.331202] i915_driver_release+0x86/0xa0 [i915] \u0026lt;4\u0026gt; [239.331482] devm_drm_dev_init_release+0x61/0x90 \u0026lt;4\u0026gt; [239.331494] devm_action_release+0x15/0x30 \u0026lt;4\u0026gt; [239.331504] release_nodes+0x3d/0x120 \u0026lt;4\u0026gt; [239.331517] devres_release_all+0x96/0xd0 \u0026lt;4\u0026gt; [239.331533] device_unbind_cleanup+0x12/0x80 \u0026lt;4\u0026gt; [239.331543] device_release_driver_internal+0x23a/0x280 \u0026lt;4\u0026gt; [239.331550] ? bus_find_device+0xa5/0xe0 \u0026lt;4\u0026gt; [239.331563] device_driver_detach+0x14/0x20 ... \u0026lt;4\u0026gt; [357.719679] ---[ end trace 0000000000000000 ]--- If the test also unloads the i915 module then that\u0027s followed with: \u0026lt;3\u0026gt; [357.787478] ============================================================================= \u0026lt;3\u0026gt; [357.788006] BUG i915_vma (Tainted: G U W N ): Objects remaining on __kmem_cache_shutdown() \u0026lt;3\u0026gt; [357.788031] ----------------------------------------------------------------------------- \u0026lt;3\u0026gt; [357.788204] Object 0xffff888109e7f480 @offset=29824 \u0026lt;3\u0026gt; [357.788670] Allocated in i915_vma_instance+0xee/0xc10 [i915] age=292729 cpu=4 pid=2244 \u0026lt;4\u0026gt; [357.788994] i915_vma_instance+0xee/0xc10 [i915] \u0026lt;4\u0026gt; [357.789290] init_status_page+0x7b/0x420 [i915] \u0026lt;4\u0026gt; [357.789532] intel_engines_init+0x1d8/0x980 [i915] \u0026lt;4\u0026gt; [357.789772] intel_gt_init+0x175/0x450 [i915] \u0026lt;4\u0026gt;  ---truncado--- Un an\u00e1lisis m\u00e1s 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\u00f3n del controlador. Todas las pruebas anteriores realizan acciones que se interrumpen activamente con se\u00f1ales. Una depuraci\u00f3n posterior ha permitido limitar este alcance a DRM_IOCTL_I915_GEM_EXECBUFFER2 y ring_context_alloc(), espec\u00edficos para el env\u00edo de anillos. Si la ejecuci\u00f3n es correcta, se supone que esa funci\u00f3n, o sus execlists o equivalentes de env\u00edo de GuC, se llamar\u00e1 solo una vez por motor de contexto GEM, seguido de la activaci\u00f3n de un indicador que impide que se vuelva a llamar. Se espera que la funci\u00f3n corrija sus errores internos por s\u00ed misma, por lo que puede volver a llamarse de forma segura despu\u00e9s de devolver un error. En caso de env\u00edo de anillo, la funci\u00f3n primero obtiene una referencia a la l\u00ednea de tiempo heredada del motor y luego asigna un VMA. Si la asignaci\u00f3n del VMA falla, por ejemplo, cuando i915_vma_instance() llamado desde dentro se interrumpe con una se\u00f1al, entonces ring_context_alloc() falla, dejando la l\u00ednea de tiempo referenciada. En la siguiente IOCTL I915_GEM_EXECBUFFER2, se obtiene otra referencia a la l\u00ednea de tiempo, y solo esta \u00faltima se coloca al completarse correctamente. Como consecuencia, la l\u00ednea de tiempo heredada, con el objeto VMA de su p\u00e1gina de estado del motor subyacente, a\u00fan se mantiene y no se libera al desvincular el controlador. Obtenga la l\u00ednea de tiempo heredada solo despu\u00e9s de la asignaci\u00f3n exitosa del VMA del motor de contexto. v2: Agregar una nota sobre otros m\u00e9todos de env\u00edo (Krzysztof Karas): Tanto los execlists como el env\u00edo GuC usan lrc_alloc(), que parec"
    }
  ],
  "id": "CVE-2025-38389",
  "lastModified": "2025-07-25T15:29:19.837",
  "metrics": {},
  "published": "2025-07-25T13:15:28.240",
  "references": [
    {
      "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
      "url": "https://git.kernel.org/stable/c/40e09506aea1fde1f3e0e04eca531bbb23404baf"
    },
    {
      "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
      "url": "https://git.kernel.org/stable/c/4c778c96e469fb719b11683e0a3be8ea68052fa2"
    },
    {
      "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
      "url": "https://git.kernel.org/stable/c/5a7ae7bebdc4c2ecd48a2c061319956f65c09473"
    },
    {
      "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
      "url": "https://git.kernel.org/stable/c/60b757730884e4a223152a68d9b5f625dac94119"
    },
    {
      "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
      "url": "https://git.kernel.org/stable/c/a5aa7bc1fca78c7fa127d9e33aa94a0c9066c1d6"
    },
    {
      "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
      "url": "https://git.kernel.org/stable/c/c542d62883f62ececafcb630a1c5010133826bea"
    },
    {
      "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
      "url": "https://git.kernel.org/stable/c/e47d7d6edc40a6ace7cc04e5893759fee68569f5"
    },
    {
      "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
      "url": "https://git.kernel.org/stable/c/f10af34261448610d4048ac6e6af87f80e3881a4"
    }
  ],
  "sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
  "vulnStatus": "Awaiting Analysis"
}


Log in or create an account to share your comment.




Tags
Taxonomy of the tags.


Loading…

Loading…

Loading…

Sightings

Author Source Type Date

Nomenclature

  • Seen: The vulnerability was mentioned, discussed, or seen somewhere by the user.
  • Confirmed: The vulnerability is confirmed from an analyst perspective.
  • Exploited: This vulnerability was exploited and seen by the user reporting the sighting.
  • Patched: This vulnerability was successfully patched by the user reporting the sighting.
  • Not exploited: This vulnerability was not exploited or seen by the user reporting the sighting.
  • Not confirmed: The user expresses doubt about the veracity of the vulnerability.
  • Not patched: This vulnerability was not successfully patched by the user reporting the sighting.


Loading…

Loading…