CVE-2025-40329
Unknown Unknown - Not Provided
BaseFortify

Publication date: 2025-12-09

Last updated on: 2025-12-09

Assigner: kernel.org

Description
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]
CVSS Scores
EPSS Scores
Probability:
Percentile:
Meta Information
Published
2025-12-09
Last Modified
2025-12-09
Generated
2026-05-07
AI Q&A
2025-12-09
EPSS Evaluated
2026-05-05
NVD
CVE-2025-40329
EUVD
EUVD-2025-201873
Affected Vendors & Products
Showing 1 associated CPE
Vendor Product Version / Range
linux kernel *
Helpful Resources
Exploitability
CWE
CWE Icon
KEV
KEV Icon
CWE ID Description
CWE-UNKNOWN
Attack-Flow Graph
AI Powered Q&A
Can you explain this vulnerability to me?

This vulnerability is a deadlock issue in the Linux kernel's DRM scheduler component. It occurs when two CPUs try to acquire locks in an interrupt-unsafe manner, specifically involving the xa_lock and fence.lock spinlocks. CPU0 holds the xa_lock while accessing job dependencies without disabling interrupts, and CPU1, running in an interrupt context, tries to acquire the same lock, causing a deadlock. Additionally, a nested locking scenario involving dma_fence_signal and dma_fence_add_callback can cause deadlocks if they share the same spinlock. The fix involved moving the code that iterates over dependencies and re-arms them out of the interrupt context to avoid these deadlocks.


How can this vulnerability impact me? :

This vulnerability can cause the Linux kernel to deadlock during DRM scheduler operations, potentially leading to system hangs or crashes when handling graphics job dependencies. This can degrade system stability and responsiveness, especially in environments relying on graphics processing, and may require a reboot to recover.


How can this vulnerability be detected on my network or system? Can you suggest some commands?

This vulnerability can be detected by monitoring the system logs for messages indicating a possible deadlock related to drm_sched_entity_kill_jobs_cb and xa_lock usage. Specifically, look for kernel log entries similar to: '[ 1231.611031] Possible interrupt unsafe locking scenario:' and '*** DEADLOCK ***'. You can use the command 'dmesg | grep drm_sched_entity_kill_jobs_cb' or 'journalctl -k | grep drm_sched_entity_kill_jobs_cb' to search for these deadlock messages in the kernel logs.


What immediate steps should I take to mitigate this vulnerability?

Immediate mitigation involves updating the Linux kernel to a version where the drm_sched_entity_kill_jobs_cb deadlock issue is fixed. The fix includes replacing all xa_* usage with their xa_*_irq counterparts and moving the code iterating on dependencies to drm_sched_entity_kill_jobs_work(). Until an update is applied, monitoring for deadlock symptoms and avoiding workloads that trigger this specific drm_sched deadlock scenario may help reduce risk.


Ask Our AI Assistant
Need more information? Ask your question to get an AI reply (Powered by our expertise)
0/70
EPSS Chart