The SCX_KICK_WAIT routine in the Linux scheduler module busy‑waits in hardirq context while awaiting a kick_sync variable. Because the CPU cannot reschedule during this wait, its own kick_sync never advances, and when multiple CPUs form a wait cycle each stalls. This results in a deadlock that immobilizes the CPU pool, effectively halting system operation. The flaw is a classic race condition that leads to a kernel lock‑up, a severe denial of service scenario. The issue was addressed by replacing the tight loop with a rescheduling call and deferring the wait to a balance callback.

This vulnerability exists in all Linux kernel releases that contain the original SCX_KICK_WAIT implementation. No version numbers are specified in the CVE data; the fixes are introduced in commits 415cb193 and c3a7903f. Any kernel built from or after these commits is considered safe. Administrators should verify that their running kernel incorporates these commits before relying on the resolution.

The deadlock can be triggered by the kernel's internal scheduling logic and does not require an external payload. No publicly documented exploits exist, and the EPSS score is unavailable. The vulnerability is not listed in CISA’s KEV catalog. Because the flaw can bring all CPU cores to a halt, it poses a significant risk if present. Patching is recommended as soon as practicable, especially on systems that run untrusted or privileged code close to the kernel.