The Linux kernel drm/v3d driver permits compute shader dispatches with a zero workgroup count to be interpreted by hardware as a large dispatch of 65,536 threads, because the hardware treats a zero value as 65536 while the driver imposes a maximum of 65535. A zero count is meant to be a no‑op, but the kernel erroneously overwrites the indirect CSD job workgroup counts with the indirect buffer ones even when they are zero and submits the job to the hardware. This leads to unintended execution of a massive compute payload or a crash, thereby compromising system stability or the stability of other applications using the GPU. The weakness results from improper input validation and manifests as a local denial‑of‑service condition. Based on the description, it is inferred that a local user who can submit DRM commands to the v3d driver may trigger this flaw, since the driver operates on user‑supplied submission buffers and the CVE does not explicitly state the exploitation vector.

All Linux kernel releases that include the drm/v3d driver are affected, with the provided CPEs covering kernel 7.1 RC1 through RC6 and all earlier builds that contain the module. Any system whose kernel has not yet incorporated the patch commit 11e6432836394e00d39e468cd514f9ddb66f1e49 should be considered vulnerable regardless of the exact kernel release number.

The EPSS score is < 1%, indicating a very low but non‑zero probability of exploitation, and the vulnerability is not listed in CISA's KEV catalog. The CVSS score of 5.5 reflects moderate severity. The CVE description indicates that the flaw occurs when the user supplies a zero workgroup count, which suggests that local users capable of issuing DRM commands could trigger the denial of service by dispatching such a compute shader. This conclusion is inferred from the description because the CVE does not explicitly provide an exploitation vector. In practice, the risk is elevated on systems that expose freely modifiable GPU workloads or rely on drm/v3d for critical operations. No public exploit has been documented, but a malicious payload could exhaust GPU resources or crash the driver, degrading system availability.