CVE-2026-63880

In the Linux kernel, the following vulnerability has been resolved:

drm/amdgpu: fix lock leak on ENOMEM in AMDGPUGEMOPGETMAPPING_INFO

The AMDGPUGEMOPGETMAPPINGINFO branch of amdgpugemopioctl() holds three cleanup-tracked resources before calling kvcalloc(): the drmgemobject reference from drmgemobjectlookup(), the drmexec lock on the looked-up GEM via drmexeclockobj(), and the drmexec lock on the per-process VM root page directory via amdgpuvmlockpd(). All three are released by the outexec 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 dmaresv 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. DRMIOCTLAMDGPUGEMOP is DRMAUTH | DRMRENDERALLOW, 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 outexec so drmexecfini() and drmgemobjectput() run.

Reproduced on stock 7.0.0-10, Ryzen 7 5700U / Radeon Vega (Lucienne): the failing ioctl returns -ENOMEM and a second GETMAPPINGINFO on the same fd then blocks in drmexeclockobj() on the leaked dmaresv. SIGKILL on the caller does not reap the task; the fd-release path during process exit goes through amdgpugemobjectclose() -> drmexecprepareobj() 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 INTMAX-bound check for args->numentries in the same branch [1]; the two patches are complementary and can land in either order.

(cherry picked from commit b69d3256d79de15f54c322986ff4da68f1d65b0a)