UBUNTU-CVE-2026-63880
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)
02 / AFFECTED SOFTWARE
Affected packages
11 explicit affected versions
4 explicit affected versions
50 explicit affected versions
6 explicit affected versions
12 explicit affected versions
19 explicit affected versions
10 explicit affected versions
6 explicit affected versions
24 explicit affected versions
2 explicit affected versions
10 explicit affected versions
26 explicit affected versions
7 explicit affected versions
13 explicit affected versions
35 explicit affected versions
1 explicit affected versions
18 explicit affected versions
1 explicit affected versions
13 explicit affected versions
4 explicit affected versions
23 explicit affected versions
1 explicit affected versions
21 explicit affected versions
16 explicit affected versions
10 explicit affected versions
7 explicit affected versions
8 explicit affected versions
7 explicit affected versions
12 explicit affected versions
11 explicit affected versions
7 explicit affected versions
12 explicit affected versions
14 explicit affected versions
1 explicit affected versions
7 explicit affected versions
12 explicit affected versions
12 explicit affected versions
9 explicit affected versions
9 explicit affected versions
16 explicit affected versions
6 explicit affected versions
10 explicit affected versions
37 explicit affected versions
13 explicit affected versions
3 explicit affected versions
10 explicit affected versions
11 explicit affected versions
26 explicit affected versions
13 explicit affected versions
29 explicit affected versions
13 explicit affected versions
12 explicit affected versions
8 explicit affected versions
33 explicit affected versions
23 explicit affected versions
10 explicit affected versions
11 explicit affected versions
5 explicit affected versions
12 explicit affected versions
7 explicit affected versions
12 explicit affected versions
17 explicit affected versions
5 explicit affected versions
10 explicit affected versions
26 explicit affected versions
11 explicit affected versions
10 explicit affected versions
13 explicit affected versions
16 explicit affected versions
10 explicit affected versions
3 explicit affected versions
7 explicit affected versions
51 explicit affected versions
18 explicit affected versions
12 explicit affected versions
27 explicit affected versions
3 explicit affected versions
8 explicit affected versions
8 explicit affected versions
3 explicit affected versions
5 explicit affected versions
8 explicit affected versions
6 explicit affected versions
10 explicit affected versions
7 explicit affected versions
13 explicit affected versions
13 explicit affected versions
7 explicit affected versions
8 explicit affected versions
10 explicit affected versions
12 explicit affected versions
9 explicit affected versions
44 explicit affected versions
16 explicit affected versions
3 explicit affected versions
13 explicit affected versions
26 explicit affected versions
45 explicit affected versions
37 explicit affected versions
14 explicit affected versions
38 explicit affected versions
9 explicit affected versions
11 explicit affected versions
7 explicit affected versions
4 explicit affected versions
1 explicit affected versions
7 explicit affected versions
13 explicit affected versions
43 explicit affected versions
10 explicit affected versions
8 explicit affected versions
14 explicit affected versions
4 explicit affected versions
78 explicit affected versions
11 explicit affected versions
1 explicit affected versions
6 explicit affected versions
03 / CONNECTIONS
Connected vulnerabilities
04 / EVIDENCE
Source records
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)
05 / REFERENCES
Further evidence
- https://git.kernel.org/linus/2e7f55eb408c3f72ee1957a0d0ad11d8648a6379
- https://ubuntu.com/security/CVE-2026-63880
- https://ubuntu.com/security/notices/USN-8593-1
- https://ubuntu.com/security/notices/USN-8603-1
- https://ubuntu.com/security/notices/USN-8618-1
- https://www.cve.org/CVERecord?id=CVE-2026-63880