CVE-2025-68203

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/amdgpu: fix lock warning in amdgpu_userq_fence_driver_process<br /> <br /> Fix a potential deadlock caused by inconsistent spinlock usage<br /> between interrupt and process contexts in the userq fence driver.<br /> <br /> The issue occurs when amdgpu_userq_fence_driver_process() is called<br /> from both:<br /> - Interrupt context: gfx_v11_0_eop_irq() -&gt; amdgpu_userq_fence_driver_process()<br /> - Process context: amdgpu_eviction_fence_suspend_worker() -&gt;<br /> amdgpu_userq_fence_driver_force_completion() -&gt; amdgpu_userq_fence_driver_process()<br /> <br /> In interrupt context, the spinlock was acquired without disabling<br /> interrupts, leaving it in {IN-HARDIRQ-W} state. When the same lock<br /> is acquired in process context, the kernel detects inconsistent<br /> locking since the process context acquisition would enable interrupts<br /> while holding a lock previously acquired in interrupt context.<br /> <br /> Kernel log shows:<br /> [ 4039.310790] inconsistent {IN-HARDIRQ-W} -&gt; {HARDIRQ-ON-W} usage.<br /> [ 4039.310804] kworker/7:2/409 [HC0[0]:SC0[0]:HE1:SE1] takes:<br /> [ 4039.310818] ffff9284e1bed000 (&amp;fence_drv-&gt;fence_list_lock){?...}-{3:3},<br /> [ 4039.310993] {IN-HARDIRQ-W} state was registered at:<br /> [ 4039.311004] lock_acquire+0xc6/0x300<br /> [ 4039.311018] _raw_spin_lock+0x39/0x80<br /> [ 4039.311031] amdgpu_userq_fence_driver_process.part.0+0x30/0x180 [amdgpu]<br /> [ 4039.311146] amdgpu_userq_fence_driver_process+0x17/0x30 [amdgpu]<br /> [ 4039.311257] gfx_v11_0_eop_irq+0x132/0x170 [amdgpu]<br /> <br /> Fix by using spin_lock_irqsave()/spin_unlock_irqrestore() to properly<br /> manage interrupt state regardless of calling context.<br /> <br /> (cherry picked from commit ded3ad780cf97a04927773c4600823b84f7f3cc2)