CVE-2026-53139: Linux DRM v3d Denial of Service via Zero Workgroup Dispatch

Technical summary

The vulnerability exists in the DRM v3d driver's compute shader dispatch (CSD) handling code. The CFG0, CFG1, and CFG2 hardware registers encode workgroup counts for a dispatch. When any dimension is zero, the submission should be rejected or skipped entirely as a no-op, not sent to hardware. However, the driver was not validating these counts before submission. For indirect CSD jobs—where workgroup counts are read from a buffer at runtime—zero counts can legitimately appear and should result in the job completing immediately without execution. The fix involves checking all three workgroup count dimensions before hardware submission and skipping the dispatch if any count is zero, while still updating the job's counts from the indirect buffer contents.

Business impact

Organizations relying on Linux systems with GPU acceleration for compute tasks may experience denial of service conditions. A local attacker with appropriate privileges can trigger kernel hangs, system instability, or forced resets by submitting malformed compute shader jobs. This impacts availability of graphics-intensive or compute-accelerated workloads, particularly in containerized environments, CI/CD pipelines using GPU resources, or workstations running untrusted code. The local-only nature (requires unprivileged user access at minimum) limits blast radius, but the ease of triggering and lack of authentication requirements make it a practical attack vector in multi-tenant or shared compute scenarios.

Affected systems

All Linux kernel versions incorporating the vulnerable DRM v3d driver are affected. This includes systems with Broadcom VideoCore V or similar v3d-compatible GPUs, commonly found in Raspberry Pi 4/5, some ARM development boards, and embedded graphics deployments. The vulnerability applies across kernel distributions and versions unless the specific patch resolving this issue has been applied. Desktop and server systems without v3d hardware are not directly affected; however, any system exposing the v3d driver interface to unprivileged processes is potentially vulnerable.

Exploitability

Exploitability is moderate. The vulnerability requires local access and sufficient privilege to submit GPU dispatch commands (typically through DRI/DRM device interfaces). In default configurations where unprivileged users have access to /dev/dri devices, any local user can trigger the condition. No authentication, network access, or user interaction is required. Exploitation is straightforward—submitting a compute shader job with zero workgroup counts requires only standard GPU API calls or direct ioctl manipulation. However, the impact is limited to denial of service; code execution is not possible. Systems with restricted GPU device access (e.g., devices only accessible to root or specific groups) have reduced practical risk.

Remediation

Apply the kernel patch that adds validation logic to skip CSD dispatch when any workgroup dimension is zero. This fix ensures indirect CSD jobs are updated with buffer-read workgroup counts but not submitted if any count is zero, allowing immediate job completion as a no-op. Users should upgrade to a patched kernel version that includes this DRM v3d fix. Verify against the vendor advisory or kernel changelog for the specific version addressing this CVE. Systems without v3d hardware (the vast majority of servers and desktops) are unaffected and require no action.

Patch guidance

Identify kernel versions and distributions affected by consulting your Linux vendor's security advisory. Verify your system uses the v3d driver by checking kernel configuration (CONFIG_DRM_V3D) and device presence (/dev/dri/renderD*). Apply kernel updates from your distribution's channels (e.g., ubuntu-security, fedora updates, debian-security) that include the DRM v3d workgroup validation fix. For systems with custom kernels, cherry-pick the patch commit that adds zero-count validation to the compute shader dispatch path. Test GPU workloads after patching to confirm stability. Kernel updates are typically applied via system package managers and require a reboot to take effect.

Detection guidance

Monitor system logs for GPU-related hangs, kernel warnings, or DRM driver errors coinciding with graphics workload submissions. Check dmesg for v3d or DRM-related panics or soft lockups. If you have GPU telemetry or job queue logging, look for spike in zero-dimension dispatch submissions from suspicious processes. On systems with mandatory access controls (SELinux, AppArmor), audit logs may show GPU device access patterns. Intrusion detection systems should flag repeated failed GPU dispatch operations. In shared compute environments, monitor for local privilege escalation or unusual GPU API calls from non-graphical contexts.

Why prioritize this

While the CVSS score of 5.5 (Medium) reflects the local-only nature and denial-of-service limitation, this vulnerability should be prioritized in environments where systems with v3d hardware are present and unprivileged users have GPU access. The ease of exploitation and broad applicability to embedded and ARM-based systems (Raspberry Pi is widely deployed) warrant timely patching. Organizations using GPU compute for critical workloads or running multi-tenant systems should apply updates promptly. For pure server or desktop environments without v3d hardware, remediation can be deferred to routine patching cycles.

Risk score, explained

The CVSS 3.1 score of 5.5 (Medium, CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H) reflects: Attack Vector Local (AV:L)—requires local system access; Access Complexity Low (AC:L)—no special conditions needed; Privileges Required Low (PR:L)—unprivileged or user-level access sufficient; User Interaction None (UI:N)—fully automated; Scope Unchanged (S:U)—impacts only the affected system; Confidentiality None (C:N)—no information disclosure; Integrity None (I:N)—no data tampering; Availability High (A:H)—causes denial of service or system hang. The score reflects that while the attack is easy and reliable for local users, it causes availability impact only, not compromise of data or execution of code.

Frequently asked questions