PT-2026-61197 · Linux · Linux
CVE-2026-63880
·
Publicado
2026-07-19
·
Atualizado
2026-07-19
Nenhuma
Não há classificações de severidade ou métricas disponíveis. Quando houver, atualizaremos as informações correspondentes na página.
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)
Encontrou algum problema na descrição? Tem algo a acrescentar? Fique à vontade para nos escrever 👾
Identificadores relacionados
Produtos afetados
Linux