Katalog CVE

CVE-2026-63880

Niskie ryzyko· EPSS 10%
Opublikowano: Zaktualizowano: Przetłumaczono: NVD NIST

Prawdopodobieństwo exploitacji (EPSS)

Niskie ryzyko
0.20%

Percentyl 10 - wyżej niż 10% wszystkich znanych CVE

Streszczenie

W jądrze Linux w sterowniku amdgpu wykryto wyciek blokady (lock leak) w funkcji AMDGPU_GEM_OP_GET_MAPPING_INFO. Błąd występuje przy niepowodzeniu alokacji pamięci (ENOMEM), co prowadzi do pominięcia zwolnienia trzech zasobów, w tym blokady dma_resv dla głównej strony katalogu VM. Powoduje to trwałe zablokowanie operacji na tej samej maszynie wirtualnej GPU, prowadząc do lokalnej odmowy usługi (DoS).

Ocena ryzyka

Organizacja narażona jest na lokalną odmowę usługi (DoS) w kontekście GPU, którą może wywołać każdy proces z dostępem do /dev/dri/renderD*. Atakujący może zablokować wszystkie dalsze operacje na maszynie wirtualnej GPU, w tym przesyłanie komend, wywłaszczanie czy działanie shrinkera TTM, aż do restartu systemu.

Rekomendacja

Należy niezwłocznie zastosować łatkę zawierającą commit b69d3256d79de15f54c322986ff4da68f1d65b0a lub zaktualizować jądro Linux do wersji zawierającej to poprawienie. W przypadku braku możliwości aktualizacji, tymczasowo ograniczyć dostęp do /dev/dri/renderD* tylko dla zaufanych procesów.

Inne podatności w Linux kernel

Zobacz wszystkie
Oryginalny opis (angielski, źródło NVD)

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)

Dane podatności pochodzą z NVD (NIST) · CISA KEV · EPSS