CVE-2026-53141

What it actually does

This is a Linux kernel Direct Rendering Manager (DRM) v3d driver reference-counting flaw in global performance monitor handling. The vulnerable paths increment a performance monitor object's reference count during SET_GLOBAL processing but fail to release that reference during some error, clear, and delete paths. Repeated use of the affected ioctl paths can leak kernel object references, preventing expected cleanup and causing resource exhaustion over time. The most likely impact is local denial of service on systems exposing the v3d DRM device to untrusted users or sandboxed workloads; there is no public evidence of code execution, privilege escalation, or remote exploitation.

Why it matters to the business

Systems using the affected Linux kernel v3d graphics driver may become unstable or unavailable if a local user or compromised application repeatedly triggers the leak. This is most relevant to Linux devices using Broadcom/V3D graphics, such as certain embedded, edge, desktop, kiosk, or single-board-computer deployments. The public exploitation likelihood is currently low based on the very low EPSS score, absence from CISA KEV, and no known exploit maturity, but unpatched shared systems can still face operational disruption from local denial-of-service abuse.

How an attack unfolds

An attacker first needs local code execution or the ability to run a process that can open the relevant DRM v3d device node, typically under /dev/dri. The attacker then creates or references v3d performance monitor objects and repeatedly invokes the global performance monitor ioctl paths, especially SET_GLOBAL, CLEAR_GLOBAL, and deletion sequences. Because the vulnerable kernel code fails to drop references in several cases, each iteration can leave kernel-side references behind. Over time, leaked references accumulate, causing resource pressure, preventing cleanup of performance monitor objects, and potentially degrading graphics-driver or system stability. Exploitation does not require network access by itself and is not known to provide direct privilege escalation; it is primarily a local resource-exhaustion condition.

How to fix it

Apply a Linux kernel update that includes the upstream drm/v3d fix for global performance monitor reference counting. If vendor-specific kernel packages are used, install the relevant distribution, device-vendor, or appliance-vendor security update once available. No exact fixed package versions were provided in the input, so remediation should be tracked through the kernel package changelog or vendor advisory referencing this fix. Where immediate patching is not possible, reduce exposure by limiting local access to v3d DRM device nodes, restricting membership in groups that can access /dev/dri devices, disabling untrusted local workloads, and applying sandbox policies that prevent access to DRM ioctls. If the v3d driver is not required on a system, consider disabling or removing the module as a compensating control, after validating operational impact.

How to confirm the fix worked

Confirm that the running kernel includes the drm/v3d reference-counting fix by checking the installed kernel version and vendor changelog, or by verifying that the relevant upstream patch is present in the kernel source/package. Validate exposure by checking whether the v3d DRM driver is loaded and whether /dev/dri device nodes are accessible to untrusted users or containers. After patching, reboot into the fixed kernel and confirm with uname -a and package-manager inventory that the expected kernel is active, not merely installed. For mitigation validation, confirm that untrusted users cannot open the relevant DRM device nodes and that sandbox/container policies deny DRM device passthrough unless explicitly required.

Typical attack path

1. Gain local ability to execute code on a Linux system using the v3d DRM driver.
2. Open the exposed v3d DRM/render device, commonly under /dev/dri.
3. Create or select v3d performance monitor objects using the driver interface.
4. Repeatedly invoke global performance monitor operations such as SET_GLOBAL, CLEAR_GLOBAL, and delete in sequences that trigger the reference leaks.
5. Accumulate unreleased kernel references until resources are exhausted or the graphics subsystem/system becomes unstable.

How to detect it

Because this flaw is a kernel reference leak, successful exploitation may leave limited direct forensic evidence unless DRM ioctl tracing, audit logging, eBPF telemetry, or endpoint process telemetry is enabled. Review auditd, EDR, eBPF, ftrace/perf, and kernel logs for processes repeatedly opening /dev/dri/card* or /dev/dri/renderD* and issuing v3d performance monitor ioctls. Look for abnormal growth in long-running local processes interacting with DRM devices, repeated crashes or hangs in graphics workloads, kernel messages involving the v3d driver, and unusual access by users or containers that normally do not require GPU/DRM access. If available, correlate device-node open events, ioctl-heavy behavior, container device passthrough, and timing of system instability. Absence of logs does not prove absence of exploitation because default Linux logging usually does not record individual DRM ioctls.

• /dev/dri/card0
• /dev/dri/renderD128
• v3d
• drm/v3d
• v3d_perfmon_find
• v3d_perfmon_set_global_ioctl
• v3d_perfmon_delete
• SET_GLOBAL
• CLEAR_GLOBAL
• PERFMON_SET_GLOBAL
• DRM_IOCTL_V3D_PERFMON_SET_GLOBAL
• DRM_IOCTL_V3D_PERFMON_CREATE
• DRM_IOCTL_V3D_PERFMON_DESTROY

What your security team should do

• Prioritize patching systems that use the v3d graphics driver and allow interactive users, containers, kiosk applications, browser sandboxes, CI jobs, or other untrusted local code to access /dev/dri devices.
• Inventory Linux assets for loaded v3d driver usage and exposed DRM/render nodes before broad emergency action, because systems without v3d are unlikely to be affected.
• Apply vendor kernel updates that include the drm/v3d global performance monitor reference-counting fix, then reboot into the fixed kernel.
• Restrict access to /dev/dri/card* and /dev/dri/renderD* devices to trusted users and workloads until patching is complete.
• Review container, VM, and sandbox configurations for unnecessary DRM device passthrough.
• Monitor affected systems for repeated v3d perfmon ioctl activity, unexplained kernel resource growth, graphics-driver instability, or local processes repeatedly opening DRM devices.
• Treat this as low internet-scale risk but meaningful local denial-of-service risk, given no KEV listing, no ransomware association, no known exploit maturity, and a very low EPSS score.