CVE-2025-40329 in Linux
Summary
by MITRE • 12/09/2025
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]
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Analysis
by VulDB Data Team • 03/30/2026
The vulnerability CVE-2025-40329 addresses a critical deadlock condition within the Linux kernel's graphics subsystem, specifically within the drm/sched component responsible for job scheduling and dependency management. This issue manifests when multiple execution contexts attempt to acquire locks in conflicting orders, creating a circular dependency that halts system progress. The problem arises from improper lock ordering between interrupt-safe and interrupt-unsafe locking operations, particularly affecting the interaction between xa_lock and fence locks during job dependency handling.
The technical flaw stems from a race condition in the drm_sched_entity_kill_jobs_cb callback function, where a function executing in interrupt context attempts to acquire a lock already held by a non-interrupt context function. The deadlock scenario occurs when CPU0 executes functions like drm_sched_job_add_dependency() or drm_sched_entity_kill_jobs_cb() without disabling interrupts, while CPU1 executes drm_sched_entity_kill_jobs_cb() as a fence signaling callback within interrupt context. This creates a classic deadlock pattern where each context waits for locks held by the other, with the xa_lock being the primary contention point between the two execution contexts.
This vulnerability directly relates to CWE-362, which describes a race condition in concurrent execution where one thread or process is blocked waiting for a resource that another thread or process holds, and to CWE-121, which covers stack-based buffer overflow conditions. The issue also maps to ATT&CK technique T1499.001, which involves network denial of service through resource exhaustion, as the deadlock can effectively freeze system operations. The fundamental problem involves improper lock hierarchy management where the same spinlock is acquired twice in different orders, creating a circular wait condition.
The operational impact of this vulnerability extends beyond simple system freezing to potentially causing complete system hangs during graphics-intensive operations. When graphics jobs are scheduled and dependencies are managed, the kernel's ability to process these operations becomes compromised, leading to application crashes, system unresponsiveness, and in severe cases, complete system lockups. This affects systems running graphics workloads including desktop environments, video rendering applications, and gaming platforms where the drm/sched subsystem is actively managing GPU job scheduling.
The mitigation strategy involves a fundamental restructuring of the dependency management code by moving the job iteration and re-arming logic from the interrupt context callback function to a dedicated workqueue function called drm_sched_entity_kill_jobs_work(). This approach eliminates the interrupt context lock acquisition that was causing the deadlock while maintaining proper synchronization through workqueue mechanisms. The solution addresses both the original interrupt safety issue and the secondary lock ordering conflict between dma_fence_signal and dma_fence_add_callback operations, ensuring that the same spinlock is not acquired twice in conflicting orders. This architectural change follows best practices for interrupt handling in kernel space and aligns with security guidelines for preventing race conditions in concurrent systems.