CVE-2025-40329

Updated on 09 Dec 2025

Severity

7.0 High severity

Details

CVSS score
7.0

Overview

About vulnerability

In the Linux kernel, the following vulnerability has been resolved: drm/sched: Fix deadlock in drm_sched_entity_kill_jobs_cb The Mesa issue referenced below pointed out a possible deadlock: [ 1231.611031] Possible interrupt unsafe locking scenario: [ 1231.611033] CPU0 CPU1 [ 1231.611034] —- —- [ 1231.611035] lock(&xa->xa_lock#17); [ 1231.611038] local_irq_disable(); [ 1231.611039] lock(&fence->lock); [ 1231.611041] lock(&xa->xa_lock#17); [ 1231.611044] <Interrupt> [ 1231.611045] lock(&fence->lock); [ 1231.611047] *** DEADLOCK *** In this example, CPU0 would be any function accessing job->dependencies through the xa_* functions that don’t disable interrupts (eg: drm_sched_job_add_dependency(), drm_sched_entity_kill_jobs_cb()). CPU1 is executing drm_sched_entity_kill_jobs_cb() as a fence signalling callback so in an interrupt context. It will deadlock when trying to grab the xa_lock which is already held by CPU0. Replacing all xa_* usage by their xa_*_irq counterparts would fix this issue, but Christian pointed out another issue: dma_fence_signal takes fence.lock and so does dma_fence_add_callback. dma_fence_signal() // locks f1.lock -> drm_sched_entity_kill_jobs_cb() -> foreach dependencies -> dma_fence_add_callback() // locks f2.lock This will deadlock if f1 and f2 share the same spinlock. To fix both issues, the code iterating on dependencies and re-arming them is moved out to drm_sched_entity_kill_jobs_work(). [phasta: commit message nits] A deadlock flaw was found in the Linux kernel’s DRM GPU scheduler. In drm_sched_entity_kill_jobs_cb(), improper locking order between the xarray lock (xa_lock) and fence lock can cause a deadlock. When CPU0 holds xa_lock and an interrupt triggers on CPU1 that requires both fence->lock and xa_lock, the system deadlocks. Additionally, if two fences share the same spinlock, calling dma_fence_add_callback() from within dma_fence_signal() creates another deadlock scenario. A local user with access to GPU resources could trigger this condition, causing a system hang.

Details

KernelCare state

Live-patch status from KernelCare for each operating system.

Operating system Status Covered kernels
Debian 13 Will Not Fix
Ubuntu 24.04 Released
39 kernels
  • 6.8.0-35.35
  • 6.8.0-38.38
  • 6.8.0-36.36
  • 6.8.0-39.39
  • 6.8.0-40.40
  • 6.8.0-41.41
  • 6.8.0-44.44
  • 6.8.0-45.45
  • 6.8.0-31.31
  • 6.8.0-47.47
  • 6.8.0-48.48
  • 6.8.0-49.49
  • 6.8.0-50.51
  • 6.8.0-51.52
  • 6.8.0-52.53
  • 6.8.0-54.56
  • 6.8.0-55.57
  • 6.8.0-53.55
  • 6.8.0-56.58
  • 6.8.0-57.59
  • 6.8.0-58.60
  • 6.8.0-59.61
  • 6.8.0-60.63
  • 6.8.0-62.65
  • 6.8.0-63.66
  • 6.8.0-64.67
  • 6.8.0-71.71
  • 6.8.0-78.78
  • 6.8.0-79.79
  • 6.8.0-84.84
  • 6.8.0-85.85
  • 6.8.0-83.83
  • 6.8.0-86.87
  • 6.8.0-87.88
  • 6.8.0-88.89
  • 6.8.0-90.91
  • 6.8.0-94.96
  • 6.8.0-100.100
  • 6.8.0-101.101
Ubuntu 24.04 AWS Planned