CVE-2025-40329

Summary

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]

Affected Software

Weaknesses

References

• https://git.kernel.org/stable/c/70150b9443dddf02157d821c68abf438f55a2e8e
• https://git.kernel.org/stable/c/0d63031ee4a57be0252cb9a4e09ae921c75cece9
• https://git.kernel.org/stable/c/3e8ada4fd838e3fd2cca94000dac054f3a347c01
• https://git.kernel.org/stable/c/487df8b698345dd5a91346335f05170ed5f29d4e

• ←Previous
• Next→