CVE-2026-53140: Linux Kernel Information Disclosure Flaw

CVE-2026-53140 Overview

CVE-2026-53140 affects the Linux kernel's Direct Rendering Manager (DRM) driver for the Broadcom VideoCore V3D GPU. The flaw resides in v3d_rewrite_csd_job_wg_counts_from_indirect(), which maps both an indirect buffer and a workgroup buffer when dispatching Compute Shader Dispatch (CSD) jobs. When any workgroup count read from the buffer is zero, the function returns early without releasing the mapped virtual addresses. This causes a memory leak of the vaddr mappings for both buffer objects (BOs) on every affected dispatch.

Critical Impact
Repeated submission of indirect CSD jobs with zeroed workgroup counts leaks kernel vaddr mappings, contributing to resource exhaustion and potential denial-of-service on systems using the V3D GPU driver.

Affected Products

Linux kernel — drivers/gpu/drm/v3d subsystem
Systems using Broadcom VideoCore V3D GPUs (commonly Raspberry Pi platforms)
Kernel versions prior to the commits referenced in the upstream stable tree

Discovery Timeline

2026-06-25 - CVE-2026-53140 published to NVD
2026-06-25 - Last updated in NVD database

Technical Details for CVE-2026-53140

Vulnerability Analysis

This is a kernel memory leak [CWE-401] in the V3D DRM driver. The function v3d_rewrite_csd_job_wg_counts_from_indirect() is invoked when a userspace client submits a CSD job whose workgroup dimensions are supplied through an indirect buffer rather than being passed directly. The driver maps both the indirect buffer object and the workgroup buffer object into kernel virtual address space to read and rewrite the dispatch counts.

The expected control flow performs the read, rewrites the workgroup counts, and then unmaps both buffer objects before returning. The defect lies in the early-exit branch that handles the case where any workgroup count value read from the indirect buffer is zero. That branch returned directly from the function, skipping the unmap cleanup and leaving both vaddr mappings allocated.

Each affected submission leaks two kernel mappings. An unprivileged process with access to the V3D render node can trigger the leak repeatedly by submitting indirect CSD jobs whose workgroup buffer contains a zero in any dimension.

Root Cause

The root cause is an incorrect error-handling path. The early return statement on the zero-workgroup-count branch bypassed the cleanup code at the end of the function. The fix replaces the direct return with a goto to the cleanup label so that the vaddr mappings are always released, regardless of which branch is taken.

Attack Vector

A local user with permission to open the V3D render node and submit GPU jobs can trigger the leak. By repeatedly submitting indirect CSD jobs whose referenced workgroup buffer contains a zero count, the user causes the kernel to leak buffer mappings on each call. Sustained abuse leads to resource exhaustion conditions affecting GPU and kernel memory subsystems.

No verified public exploit code is associated with this issue. The vulnerability mechanism is described in the upstream commit messages referenced in the Linux Kernel stable tree.

Detection Methods for CVE-2026-53140

Indicators of Compromise

Sustained growth in kernel memory usage attributable to the V3D driver without corresponding workload increase.
Userspace processes repeatedly submitting CSD jobs to /dev/dri/renderD* nodes with indirect workgroup buffers containing zero values.
dmesg warnings related to vmap exhaustion or DRM buffer object accounting anomalies over long runtimes.

Detection Strategies

Monitor /proc/meminfoVmallocUsed and per-driver allocations on systems using V3D over extended periods to identify unbounded growth.
Audit kernel versions on Raspberry Pi and other Broadcom VideoCore-based fleets against the patched stable releases referenced in the upstream commits.
Correlate GPU submission telemetry with kernel memory metrics to flag processes generating high-volume indirect CSD dispatches.

Monitoring Recommendations

Track kernel slab and vmalloc trends with node-level telemetry collectors and alert on sustained non-decreasing growth.
Log access to DRM render nodes and review which userspace processes hold sessions on V3D devices.
Forward kernel logs to a centralized analytics platform to retain history for post-incident review.

How to Mitigate CVE-2026-53140

Immediate Actions Required

Apply the upstream Linux kernel patches that replace the early return with a goto to the cleanup label in v3d_rewrite_csd_job_wg_counts_from_indirect().
Update affected systems to a stable kernel release that includes the fix commits referenced by the upstream maintainers.
Restrict access to V3D render nodes to trusted local users where patching cannot be completed immediately.

Patch Information

The fix is available in the Linux stable tree. See the upstream commits: commit 0b59d094, commit 60ebeb23, commit 90b62926, and commit ae767695. Distribution-supplied kernels should be updated once vendors backport the change.

Workarounds

Limit which local accounts can open /dev/dri/renderD* nodes through group membership and udev rules.
Reboot long-running systems periodically to reclaim leaked mappings until the patched kernel is deployed.
Avoid running untrusted workloads that submit indirect CSD jobs on unpatched V3D-enabled hosts.

bash

# Verify running kernel and check for the fix commits in the changelog
uname -r
zcat /proc/config.gz | grep -i CONFIG_DRM_V3D
# Restrict render node access to a specific group
sudo groupadd -f render
sudo chgrp render /dev/dri/renderD128
sudo chmod 0660 /dev/dri/renderD128