CVE-2026-53139

What it actually does

This is an improper input validation flaw in the Linux kernel V3D DRM driver. An indirect compute shader dispatch can supply a zero workgroup count in one or more dimensions. The driver should treat that as a no-op, but vulnerable code can submit the job to hardware, where a zero value is interpreted as 65,536 workgroups. A local process with access to the V3D DRM device can therefore cause unintended oversized GPU compute execution, potentially leading to GPU job timeouts, resets, resource exhaustion, or denial of service on systems using the affected driver.

Why it matters to the business

Systems that rely on the affected Linux V3D graphics driver may experience graphics or compute instability, degraded performance, application failures, or device hangs if a local user or compromised application triggers the bug. The risk is most relevant to devices using Broadcom V3D-class GPUs, such as embedded, edge, kiosk, desktop, or development systems where untrusted workloads can access GPU render nodes. This issue is not listed in CISA KEV, is not known to be used in ransomware campaigns, and currently has low EPSS likelihood, so it is generally a patch-management priority rather than an emergency internet-exposure event.

How an attack unfolds

An attacker first needs local code execution or the ability to run a GPU-capable application with access to the V3D DRM render device. They create an indirect compute shader dispatch where one of the workgroup dimensions resolves to zero. In vulnerable kernels, the driver can pass that zero-valued dispatch to the hardware instead of completing it as a no-op. The hardware interprets the zero field as 65,536, causing a much larger compute workload than intended. Repeated or carefully timed submissions can consume GPU resources, cause job timeouts, trigger driver or GPU resets, and disrupt workloads sharing the graphics subsystem. There is no indication from the supplied data of public exploit maturity, known threat actor use, or remote unauthenticated exploitation.

How to fix it

Upgrade to a Linux kernel version that includes the V3D DRM fix for zero-workgroup indirect compute shader dispatch handling. The corrected behavior overwrites indirect CSD job workgroup counts from the indirect buffer even when they are zero and skips hardware submission when any workgroup dimension is zero. If vendor kernels are used, apply the relevant distribution, appliance, or board-vendor kernel update rather than relying only on upstream version numbers. Where immediate patching is not possible, reduce risk by restricting local access to /dev/dri/card* and /dev/dri/renderD* devices, disabling untrusted GPU compute workloads, limiting membership in groups that grant DRM access, and applying container/device policies that prevent untrusted workloads from using the V3D render node.

How to confirm the fix worked

Confirm the running kernel contains the V3D DRM patch that skips compute shader dispatches with zero workgroup dimensions. Validate using vendor advisory status, kernel changelog entries, or source inspection for the V3D CSD path behavior. On live systems, verify the active booted kernel is the patched package, not merely installed. Where practical, run a controlled regression test that submits an indirect CSD job with a zero workgroup dimension and confirm it completes as a no-op without GPU timeout, reset, excessive runtime, or kernel errors. Also review device access controls to confirm untrusted users or containers cannot access V3D DRM devices unless required.

Typical attack path

1. Gain local ability to run code on a system using the Linux V3D DRM driver.
2. Obtain access to a DRM render or card device, commonly under /dev/dri/.
3. Submit an indirect compute shader dispatch through the V3D DRM interface.
4. Set one or more indirect workgroup-count dimensions to zero.
5. Cause vulnerable kernel code to submit the dispatch to hardware instead of treating it as a no-op.
6. Trigger oversized GPU execution, GPU job timeout, reset, or denial-of-service conditions.
7. Repeat submissions to sustain instability or disrupt graphics/compute workloads.

How to detect it

To determine whether this was already exploited or triggered, review kernel and system logs for V3D DRM errors, GPU hangs, job timeouts, resets, or abnormal compute-shader activity. Useful sources include dmesg, journald, /var/log/kern.log, /var/log/messages, auditd records for /dev/dri access, endpoint telemetry showing processes opening DRM render nodes, and eBPF or syscall traces capturing DRM ioctl usage. Correlate GPU reset or timeout messages with processes that had /dev/dri/renderD* or /dev/dri/card* open at the same time. Look for repeated failures caused by the same local process, container, user session, or graphics workload. Because no exploit-specific public indicators are provided, detection should focus on behavioral evidence: V3D CSD job failures, sudden GPU resets, high GPU utilization from unexpected local processes, repeated DRM ioctls, and access to V3D render devices by untrusted applications.

• /dev/dri/renderD
• /dev/dri/card
• DRM_IOCTL_V3D_SUBMIT_CSD
• SUBMIT_CSD
• v3d
• drm/v3d
• V3D
• CSD
• compute shader dispatch
• GPU hang
• gpu hang
• job timeout
• timeout waiting for
• resetting GPU
• GPU reset
• drm error
• /var/log/kern.log
• /var/log/messages

What your security team should do

• Inventory Linux systems using the V3D DRM driver or Broadcom V3D-class GPUs.
• Prioritize patching exposed multi-user, kiosk, shared desktop, embedded, CI, or container-host systems where untrusted local workloads may access GPU devices.
• Apply the appropriate vendor kernel update and reboot into the fixed kernel.
• Until patched, restrict permissions to /dev/dri/card* and /dev/dri/renderD* and remove unnecessary users or services from GPU-access groups.
• For containerized workloads, ensure device passthrough does not expose V3D DRM nodes to untrusted containers.
• Monitor kernel logs for V3D GPU hangs, job timeouts, resets, or repeated DRM errors.
• Investigate local processes that repeatedly open DRM render nodes and correlate them with GPU instability events.
• Treat this as a local denial-of-service class issue unless additional vendor information indicates broader impact.