The Linux kernel drm/v3d driver mistakenly allows compute shader dispatches that specify a zero workgroup count to be processed as if the count were 65,536. Hardware therefore interprets a zero value as a massive dispatch, enabling a potentially large number of compute threads to execute when a zero was intended to be a no‑op. This misinterpretation can lead to excessive resource consumption or a crash, effectively creating a denial‑of‑service condition for the system or for other applications that rely on stable GPU behavior. The vulnerability is an example of improper input validation and results in the execution of unintended compute payloads.

All Linux kernel builds that include the drm/v3d driver are affected. No specific version range is provided, so any kernel prior to the application of the specified patch should be considered vulnerable. The driver runs in kernel space and interfaces with user‑space GPU applications, meaning that any process able to issue GPU workload submissions could trigger the flaw.

The CVSS, EPSS, and KEV metrics are not reported for this issue, but the lack of a public exploit and the requirement to submit a GPU dispatch suggest that the vulnerability is of moderate severity. Local users with the ability to issue DRM commands could potentially cause a denial of service, while unprivileged exploitation would still be limited to the GPU context of the user. The risk is higher on systems that expose freely modifiable GPU workloads or where the drm/v3d driver is used for non‑reliable workloads. No publicly documented exploits exist at the time of analysis, but the potential for a system crash or resource exhaustion is clear.