CVE-2026-63880 in Linux
Summary
by MITRE • 07/19/2026
In the Linux kernel, the following vulnerability has been resolved:
drm/amdgpu: fix lock leak on ENOMEM in AMDGPU_GEM_OP_GET_MAPPING_INFO
The AMDGPU_GEM_OP_GET_MAPPING_INFO branch of amdgpu_gem_op_ioctl() holds three cleanup-tracked resources before calling kvcalloc(): the drm_gem_object reference from drm_gem_object_lookup(), the drm_exec lock on the looked-up GEM via drm_exec_lock_obj(), and the drm_exec lock on the per-process VM root page directory via amdgpu_vm_lock_pd(). All three are released by the out_exec label that every other error path in this function jumps to. The kvcalloc() failure path returns -ENOMEM directly, skipping out_exec and leaking all three.
The leaked per-process VM root PD dma_resv lock is the load-bearing leak: any subsequent operation on the same VM (further GEM ops, command-submission, eviction, TTM shrinker callbacks) blocks on the held lock. DRM_IOCTL_AMDGPU_GEM_OP is DRM_AUTH | DRM_RENDER_ALLOW, so this is an unprivileged-local denial of service against the caller's GPU context, reachable by any process with /dev/dri/renderD* access.
Route the failure through out_exec so drm_exec_fini() and drm_gem_object_put() run.
Reproduced on stock 7.0.0-10, Ryzen 7 5700U / Radeon Vega (Lucienne): the failing ioctl returns -ENOMEM and a second GET_MAPPING_INFO on the same fd then blocks in drm_exec_lock_obj() on the leaked dma_resv. SIGKILL on the caller does not reap the task; the fd-release path during process exit goes through amdgpu_gem_object_close() -> drm_exec_prepare_obj() on the same lock, leaving the task in D state until the box is rebooted. The patched kernel was not rebuilt and re-tested on this hardware; the fix is mechanical. Tested on a single Lucienne / Vega box only.
Ziyi Guo posted an independent INT_MAX-bound check for args->num_entries in the same branch [1]; the two patches are
complementary and can land in either order.
(cherry picked from commit b69d3256d79de15f54c322986ff4da68f1d65b0a)
VulDB is the best source for vulnerability data and more expert information about this specific topic.
Analysis
by VulDB Data Team • 07/19/2026
The vulnerability resides within the Linux kernel's AMDGPU driver, specifically in the drm/amdgpu subsystem where a lock leak occurs during memory allocation failure. This issue manifests in the AMDGPU_GEM_OP_GET_MAPPING_INFO operation of the amdgpu_gem_op_ioctl() function, which manages Graphics Execution Manager (GEM) object operations for AMD graphics hardware. The flaw represents a classic resource management error where cleanup paths are not properly executed upon certain failure conditions.
During normal execution flow, the function acquires three distinct resources that require proper cleanup: a GEM object reference obtained through drm_gem_object_lookup(), a drm_exec lock on the looked-up GEM via drm_exec_lock_obj(), and a drm_exec lock on the per-process VM root page directory utilizing amdgpu_vm_lock_pd(). These resources are all designed to be released through a common error handling label named out_exec, which serves as the standard cleanup routine for all other failure paths within this function. However, when kvcalloc() fails due to memory exhaustion, the function returns -ENOMEM directly without traversing the out_exec path.
The critical aspect of this vulnerability stems from the fact that one of the three leaked resources is particularly harmful: the per-process VM root PD dma_resv lock. This lock represents a fundamental synchronization primitive within the AMDGPU driver's virtual memory management system. When this specific lock remains acquired due to the missing cleanup path, it creates a deadlock condition that affects all subsequent operations on the same virtual memory context. Any further GEM operations, command submissions, eviction requests, or TTM shrinker callbacks targeting the same VM will block indefinitely waiting for the held lock, effectively creating a denial of service condition.
This vulnerability operates at the kernel level and presents an unprivileged local denial of service attack vector that can be exploited by any process possessing access to the /dev/dri/renderD* device nodes. The DRM_IOCTL_AMDGPU_GEM_OP ioctl command is configured with DRM_AUTH | DRM_RENDER_ALLOW flags, meaning it accepts operations from userspace processes that have been authenticated and granted render permissions, making the attack surface quite broad. The impact extends beyond simple process termination as demonstrated by the test case showing that even SIGKILL signals cannot properly reap the affected task.
The operational consequences of this vulnerability are severe and persistent, with the affected process entering an uninterruptible D state until system reboot occurs. This behavior is consistent with the kernel's handling of deadlocked locks where processes become stuck waiting for resources they cannot release. During normal process exit, the fd-release path attempts to clean up through amdgpu_gem_object_close() followed by drm_exec_prepare_obj() on the same leaked lock, creating a circular dependency that prevents proper resource cleanup. The fix implemented involves routing the kvcalloc() failure path through the established out_exec label to ensure all three tracked resources receive proper cleanup, specifically calling drm_exec_fini() and drm_gem_object_put() functions.
This issue aligns with CWE-772 (Missing Release of Resource after Effective Lifetime) and demonstrates poor error handling practices in kernel space memory management. From an ATT&CK perspective, this represents a local privilege escalation vector that could be leveraged to create persistent denial of service conditions against GPU contexts, potentially affecting system stability and performance. The vulnerability is particularly concerning because it affects the core graphics subsystem and can be triggered through legitimate GEM operations without requiring escalated privileges, making it a significant concern for systems with active GPU usage.
The fix addresses the root cause by ensuring consistent resource cleanup regardless of error paths within the function, maintaining proper synchronization semantics throughout the driver's operation. This mechanical patch approach directly addresses the specific issue identified in the commit referenced from b69d3256d79de15f54c322986ff4da68f1d65b0a and provides a robust solution that maintains the existing functionality while preventing the resource leak that leads to the denial of service condition. The complementary nature of the fix, combined with Ziyi Guo's independent patch addressing an INT_MAX-bound check for args->num_entries in the same branch, demonstrates the comprehensive approach taken to address multiple related issues in this code path.