CVE-2026-63880

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/amdgpu: fix lock leak on ENOMEM in AMDGPU_GEM_OP_GET_MAPPING_INFO<br /> <br /> The AMDGPU_GEM_OP_GET_MAPPING_INFO branch of amdgpu_gem_op_ioctl()<br /> holds three cleanup-tracked resources before calling kvcalloc():<br /> the drm_gem_object reference from drm_gem_object_lookup(), the<br /> drm_exec lock on the looked-up GEM via drm_exec_lock_obj(), and<br /> the drm_exec lock on the per-process VM root page directory via<br /> amdgpu_vm_lock_pd(). All three are released by the out_exec<br /> label that every other error path in this function jumps to.<br /> The kvcalloc() failure path returns -ENOMEM directly, skipping<br /> out_exec and leaking all three.<br /> <br /> The leaked per-process VM root PD dma_resv lock is the<br /> load-bearing leak: any subsequent operation on the same VM<br /> (further GEM ops, command-submission, eviction, TTM shrinker<br /> callbacks) blocks on the held lock. DRM_IOCTL_AMDGPU_GEM_OP is<br /> DRM_AUTH | DRM_RENDER_ALLOW, so this is an unprivileged-local<br /> denial of service against the caller&amp;#39;s GPU context, reachable<br /> by any process with /dev/dri/renderD* access.<br /> <br /> Route the failure through out_exec so drm_exec_fini() and<br /> drm_gem_object_put() run.<br /> <br /> Reproduced on stock 7.0.0-10, Ryzen 7 5700U / Radeon Vega<br /> (Lucienne): the failing ioctl returns -ENOMEM and a second<br /> GET_MAPPING_INFO on the same fd then blocks in<br /> drm_exec_lock_obj() on the leaked dma_resv. SIGKILL on the<br /> caller does not reap the task; the fd-release path during<br /> process exit goes through amdgpu_gem_object_close() -&gt;<br /> drm_exec_prepare_obj() on the same lock, leaving the task in D<br /> state until the box is rebooted. The patched kernel was not<br /> rebuilt and re-tested on this hardware; the fix is mechanical.<br /> Tested on a single Lucienne / Vega box only.<br /> <br /> Ziyi Guo posted an independent INT_MAX-bound check for<br /> args-&gt;num_entries in the same branch [1]; the two patches are<br /> complementary and can land in either order.<br /> <br /> (cherry picked from commit b69d3256d79de15f54c322986ff4da68f1d65b0a)