CVE-2025-40329

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/sched: Fix deadlock in drm_sched_entity_kill_jobs_cb<br /> <br /> The Mesa issue referenced below pointed out a possible deadlock:<br /> <br /> [ 1231.611031] Possible interrupt unsafe locking scenario:<br /> <br /> [ 1231.611033] CPU0 CPU1<br /> [ 1231.611034] ---- ----<br /> [ 1231.611035] lock(&amp;xa-&gt;xa_lock#17);<br /> [ 1231.611038] local_irq_disable();<br /> [ 1231.611039] lock(&amp;fence-&gt;lock);<br /> [ 1231.611041] lock(&amp;xa-&gt;xa_lock#17);<br /> [ 1231.611044] <br /> [ 1231.611045] lock(&amp;fence-&gt;lock);<br /> [ 1231.611047]<br /> *** DEADLOCK ***<br /> <br /> In this example, CPU0 would be any function accessing job-&gt;dependencies<br /> through the xa_* functions that don&amp;#39;t disable interrupts (eg:<br /> drm_sched_job_add_dependency(), drm_sched_entity_kill_jobs_cb()).<br /> <br /> CPU1 is executing drm_sched_entity_kill_jobs_cb() as a fence signalling<br /> callback so in an interrupt context. It will deadlock when trying to<br /> grab the xa_lock which is already held by CPU0.<br /> <br /> Replacing all xa_* usage by their xa_*_irq counterparts would fix<br /> this issue, but Christian pointed out another issue: dma_fence_signal<br /> takes fence.lock and so does dma_fence_add_callback.<br /> <br /> dma_fence_signal() // locks f1.lock<br /> -&gt; drm_sched_entity_kill_jobs_cb()<br /> -&gt; foreach dependencies<br /> -&gt; dma_fence_add_callback() // locks f2.lock<br /> <br /> This will deadlock if f1 and f2 share the same spinlock.<br /> <br /> To fix both issues, the code iterating on dependencies and re-arming them<br /> is moved out to drm_sched_entity_kill_jobs_work().<br /> <br /> [phasta: commit message nits]