CVE-2026-53140

What it actually does

This is a Linux kernel v3d DRM driver resource-cleanup flaw. When handling an indirect compute shader dispatch, the driver maps both an indirect buffer and a workgroup-count buffer into kernel virtual address space. If any workgroup count is zero, the vulnerable path returns before unmapping those buffers, leaking kernel virtual address mappings. A local process with access to the v3d DRM render device could repeatedly trigger the condition and consume kernel mapping resources, potentially causing GPU driver instability, kernel memory pressure, denial of service, or system instability. The available description does not indicate a practical path to code execution or data disclosure.

Why it matters to the business

Systems using the affected Linux kernel v3d graphics driver may be vulnerable to local denial-of-service conditions. The most likely operational impact is degraded graphics/GPU compute functionality, process failures, or host instability if an untrusted local user, sandbox escape context, or container with GPU device access can repeatedly trigger the bug. Public exploitation is not currently indicated, EPSS is low, and it is not listed in CISA KEV, so this should generally be prioritized behind actively exploited kernel issues unless the organization exposes v3d GPU devices to untrusted workloads.

How an attack unfolds

An attacker first needs local execution on a system where the vulnerable v3d DRM driver is loaded and where the attacker can open the relevant DRM render device, such as through normal desktop access, a local user account, or a container granted GPU device access. The attacker prepares GPU buffer objects used for an indirect compute shader dispatch and sets one or more workgroup counts to zero. They then submit the crafted compute dispatch to the v3d driver. The vulnerable function maps the indirect and workgroup buffers, detects the zero workgroup count, and exits through the wrong path without releasing the kernel virtual address mappings. Repeating the submission can accumulate leaked mappings until kernel virtual address space or related resources are exhausted, leading to failures in the graphics stack, driver errors, or broader system instability. There is no public indication from the supplied data that this issue is being exploited in the wild or used by ransomware campaigns.

How to fix it

Upgrade to a Linux kernel or vendor kernel package that includes the v3d driver fix for the cleanup path in v3d_rewrite_csd_job_wg_counts_from_indirect(). Because no exact fixed versions were provided, use the fixed kernel builds published by the operating system, appliance, or device vendor and verify the relevant stable-kernel backport is included. If immediate patching is not possible, reduce exposure by disabling the v3d driver where it is not required, removing GPU device access from untrusted containers or sandboxes, restricting membership in groups that can access /dev/dri/renderD* devices, and applying udev or device-cgroup policy to limit access to DRM render nodes. These mitigations reduce exploitability but do not correct the kernel bug.

How to confirm the fix worked

Confirm whether systems load the v3d driver and run a kernel build that includes the upstream or vendor backport for this issue. Check kernel package changelogs, vendor advisories, or source patches for the corrected cleanup behavior in v3d_rewrite_csd_job_wg_counts_from_indirect(). Validate that untrusted users and containers cannot access v3d DRM render devices unless required. After patching, reboot into the fixed kernel and confirm the running kernel version, loaded module version, and package inventory reflect the updated build. Where safe test coverage exists, run graphics/GPU compute regression tests and monitor kernel logs for v3d errors, vmalloc failures, GPU hangs, or abnormal memory-map growth under malformed or boundary-condition compute workloads.

Typical attack path

1. Gain local code execution on a Linux system using the affected v3d DRM driver.
2. Confirm access to the DRM render node or other device interface that accepts v3d compute shader dispatch submissions.
3. Create GPU buffer objects for an indirect compute shader dispatch.
4. Set at least one indirect workgroup count to zero to trigger the vulnerable early-return path.
5. Submit the crafted job to the v3d driver.
6. Repeat the submission to leak kernel virtual address mappings over time.
7. Cause GPU driver malfunction, kernel memory/resource pressure, or denial of service.

How to detect it

To assess possible prior exploitation, focus on local telemetry from systems using the v3d DRM driver. Review kernel logs via dmesg, journald, syslog, or centralized Linux log collection for recurring v3d driver errors, GPU hangs, vmalloc or virtual memory allocation failures, OOM-killer activity, and abrupt graphics stack resets. Correlate these events with process execution, auditd, eBPF, or EDR telemetry showing processes opening DRM render devices and issuing unusually frequent DRM/v3d ioctl calls. In containerized environments, review runtime configuration and audit logs for containers granted /dev/dri device access, especially if instability coincides with untrusted workloads. Because the flaw is a resource leak rather than a payload-dropping vulnerability, exploitation may leave no durable file artifact; detection is primarily behavioral and log-correlation based.

What your security team should do

• Inventory Linux systems that use Broadcom v3d graphics support or have the v3d DRM driver loaded.
• Prioritize patching systems where untrusted users, shared desktops, kiosks, CI workloads, containers, or sandboxed applications have access to /dev/dri devices.
• Apply the vendor-fixed kernel package and reboot into the fixed kernel; confirm the old vulnerable kernel is not still running.
• Restrict GPU device pass-through to containers and virtualized workloads unless there is a clear business requirement.
• Limit local access to DRM render nodes through group membership, udev rules, and device-cgroup policy until patching is complete.
• Monitor kernel logs and endpoint telemetry for repeated GPU driver failures, vmalloc exhaustion, OOM events, or suspicious high-rate DRM ioctl activity from untrusted processes.
• Treat this as a local denial-of-service risk rather than a remote compromise risk unless new exploit information emerges.