CVE-2025-68223

What it actually does

A race condition in the radeon fence signaling path can cause self-deadlock when signaled() is invoked while holding the fence lock that doubles as the wait queue lock, leading to system hang or denial of service.

Why it matters to the business

Systems using the affected Linux kernel may experience unexpected freezes or crashes during graphics operations, disrupting workloads and requiring reboots until the kernel is updated.

How an attack unfolds

A local attacker with low privileges triggers repeated fence operations on radeon hardware in a way that causes signaled() to be called under the contended lock, deadlocking the wait queue and halting the system.

How to fix it

Update the Linux kernel to a version containing commit d40a72d7e3bad4dfb311ef078f5a57362f088c7f or later; for affected container images update kserve-rest-proxy and kserve-rest-proxy-compat to 0.12.0-r4 or newer.

How to confirm the fix worked

Verify the running kernel contains the fix by checking git commit history or package version; confirm no deadlock occurs under sustained fence signaling workloads on radeon hardware.

Typical attack path

1. Obtain local user access on a system with radeon GPU and the vulnerable kernel
2. Exercise graphics or DMA fence operations that invoke dma_fence_ops::signaled while the internal lock is held
3. Force the radeon_fence_process call path to contend on the same lock, inducing deadlock

How to detect it

Review kernel logs for radeon fence-related deadlocks or hung tasks; no public exploitation artifacts are known, so focus on post-update stability rather than historical indicators.

What your security team should do

• Prioritize kernel updates on all systems exposing radeon GPUs within the next patch cycle
• Monitor for availability impact on graphics-dependent workloads until patches are applied
• Apply the exact fixed package versions listed for each distribution or image