CVE-2026-53141: Linux Kernel DRM v3d Memory Leak Denial of Service

Technical summary

This vulnerability stems from improper reference counting in v3d_perfmon_find() and related functions within the DRM v3d driver. The SET_GLOBAL ioctl increments a reference count on a performance monitor object, but the kernel fails to decrement it in error paths and cleanup routines. Specifically: (1) v3d_perfmon_set_global_ioctl() leaks references when error conditions are encountered; (2) CLEAR_GLOBAL fails to release both the newly-found reference and the previously-stashed global perfmon reference; and (3) destroying a perfmon that is currently configured as the global perfmon leaks the reference set during initialization. These unreleased references prevent kernel memory from being reclaimed, leading to gradual memory exhaustion.

Business impact

Organizations running vulnerable Linux kernels on systems with active GPU workloads or development environments face potential service disruption. Repeated exploitation could lead to kernel out-of-memory conditions, forcing system reboots and interrupting legitimate graphics processing workloads. For servers providing GPU compute resources (AI/ML training, rendering farms, CUDA environments), this can cause unplanned downtime. The impact is primarily availability-focused rather than confidentiality or integrity, but persistent memory leaks are operationally significant.

Affected systems

All Linux kernel versions affected by this vulnerability (specific version range to be confirmed in vendor advisories) are impacted. Systems are at risk only if: (1) the v3d graphics driver is compiled into the kernel or loaded as a module, and (2) unprivileged local users have access to GPU ioctls. This primarily affects development machines, workstations with dedicated GPUs, and servers running GPU-accelerated workloads. Embedded systems using v3d and systems with restricted user access have lower practical risk.

Exploitability

Exploitability is straightforward for attackers with local system access. No special knowledge or public exploit code is required—the vulnerability can be triggered through standard GPU management ioctls available to unprivileged users. However, the attack requires: local user access (not remote), ability to issue GPU commands, and time to accumulate sufficient memory leaks for observable impact. This classifies the vulnerability as locally exploitable but not remotely triggerable. The CVSS score of 5.5 reflects the local-only attack vector and high availability impact.

Remediation

Remediation requires patching the Linux kernel to incorporate fixes for the three reference-counting paths identified in CVE-2026-53141. The patch explicitly releases references in v3d_perfmon_set_global_ioctl() error paths, CLEAR_GLOBAL ioctl cleanup, and perfmon object destruction. Patches should be obtained from your Linux distribution's security repository or directly from kernel.org once released. For systems unable to patch immediately, restricting unprivileged access to GPU resources through device permissions (/dev/dri/*) can reduce exposure.

Patch guidance

Apply kernel security updates from your distribution (Red Hat, Debian, Ubuntu, SUSE, etc.) as they become available. Verify the update addresses CVE-2026-53141 specifically in the DRM v3d driver code. Kernel versions should be cross-referenced against the official Linux Security Advisory. Most distributions will backport fixes to supported stable branches (e.g., 6.1.x, 6.6.x, 6.9.x) rather than requiring upgrade to the latest kernel. Test patches in non-production environments first, as kernel updates require system restart.

Detection guidance

Monitor kernel memory usage patterns for gradual growth without corresponding freed memory—tools like 'free', 'top', and '/proc/meminfo' will show increasing MemUsed with stable MemAvailable. Enable kernel memory leak detection if available (CONFIG_KMEMLEAK). Watch system logs for GPU driver warnings or memory pressure events. On systems with restricted GPU access, privilege audit logs can reveal suspicious GPU ioctl usage. However, reliable detection of active exploitation is difficult without kernel debug symbols and memory analysis tools.

Why prioritize this

While the CVSS score is moderate (5.5), prioritization depends on your infrastructure. Rate as HIGH if: systems have active GPU workloads, multiple unprivileged users can access GPU resources, or the kernel version is confirmed vulnerable. Rate as MEDIUM if: GPU access is restricted to trusted users or GPU usage is minimal. Rate as LOW if: v3d driver is not in use or GPU device access is completely restricted. The lack of KEV status and public exploits suggests this is not yet weaponized, but the trivial attack surface warrants timely patching.

Risk score, explained

CVSS 5.5 (Medium) reflects: local-only attack vector (AV:L), low attack complexity (AC:L), low privilege requirement (PR:L), no user interaction needed (UI:N), single security domain (S:U), no confidentiality impact (C:N), no integrity impact (I:N), but high availability impact (A:H). The score appropriately captures that while privilege escalation is not possible, an unprivileged user can reliably degrade system availability through memory exhaustion. Organizations with high-security posture may treat this as more critical given the availability impact in production environments.

Frequently asked questions