CVE-2026-63880 Details
Description
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)
A denial-of-service vulnerability has been identified in the Linux kernel's AMDGPU graphics driver. The issue arises in the GEM operation 'AMDGPU_GEM_OP_GET_MAPPING_INFO' within the 'amdgpu_gem_op_ioctl' function. When the function attempts to allocate memory using 'kvcalloc()', a failure can occur, returning an 'ENOMEM' error. This failure path, however, bypasses the necessary cleanup process, leading to a leak of three critical resources: a reference to the GEM object, a lock on the executed GEM, and a lock on the per-process virtual memory root page directory. The leaked lock on the virtual memory directory is particularly problematic, as it blocks any subsequent operations on the same virtual memory, such as further GEM operations or command submissions, creating a local denial-of-service condition for the affected GPU context. This vulnerability can be exploited by any process with access to the '/dev/dri/renderD*' devices.
Users can upgrade to the patched version of the Linux kernel where this vulnerability has been addressed. The specific commit containing the fix is available in the Linux kernel stable tree.
Metrics
CVSS 4.0 Severity and Vector Strings:
No CVSS 4.0 data is available for this CVE.
CVSS 3.x Severity and Vector Strings:
No CVSS 3.x data is available for this CVE.
No data available for CVSS Version 2.0 on this CVE.
No SSVC data is available for this CVE.
References to Advisories, Solutions, and Tools
By selecting these links, you will be leaving this site. These are references gathered from the official CVE record and are not endorsed by Volerion.
Weakness Enumeration
No weakness enumeration is available for this CVE.
Affected Products
No affected product data is available for this CVE.
Change History
1 change record found show changes
| Date | Action | Recorded By |
|---|---|---|
| Jul 19, 2026 | New CVE Received | kernel.org |