CVE-2026-63880 in Linux
Zusammenfassung
von VulDB • 20.07.2026
Im Linux-Kernel wurde folgende Schwachstelle behoben:
drm/amdgpu: Behebung eines Lock-Lecks bei ENOMEM in AMDGPU_GEM_OP_GET_MAPPING_INFO
Der Zweig `AMDGPU_GEM_OP_GET_MAPPING_INFO` von `amdgpu_gem_op_ioctl()` hält drei bereinigungsgetrackte Ressourcen, bevor er `kvcalloc()` aufruft: die Referenz auf das `drm_gem_object` aus `drm_gem_object_lookup()`, den `drm_exec`-Lock für das nachgeschlagene GEM über `drm_exec_lock_obj()` und den `drm_exec`-Lock für das pro-Prozess-VM-Wurzel-Seitennachschlagetabellenverzeichnis (Page Directory) über `amdgpu_vm_lock_pd()`. Alle drei werden durch die Marke `out_exec` freigegeben, zu der jeder andere Fehlerpfad in dieser Funktion springt. Der Fehlersprungpfad von `kvcalloc()` gibt -ENOMEM direkt zurück und überspringt dabei `out_exec`, wodurch alle drei Ressourcen geleakt werden.
Der geleckte dma_resv-Lock des pro-Prozess-VM-Wurzel-PD ist der kritische Leak: Jeder nachfolgende Vorgang auf derselben VM (weitere GEM-Vorgänge, Befehlsübermittlung, Eviction, TTM-Shrinker-Rückrufe) blockiert am gehaltenen Lock. `DRM_IOCTL_AMDGPU_GEM_OP` hat die Flags `DRM_AUTH | DRM_RENDER_ALLOW`, sodass dies eine nicht privilegierte lokale Denial-of-Service-Angriff (DoS) gegen den GPU-Kontext des Aufrufers darstellt, der von jedem Prozess mit Zugriff auf `/dev/dri/renderD*` erreichbar ist.
Der Fehlersprungpfad wird nun über `out_exec` geleitet, sodass `drm_exec_fini()` und `drm_gem_object_put()` ausgeführt werden.
Reproduziert unter Stock-Kernel 7.0.0-10 auf Ryzen 7 5700U / Radeon Vega (Lucienne): Der fehlschlagende ioctl gibt -ENOMEM zurück, und ein zweiter GET_MAPPING_INFO-Aufruf auf demselben Dateideskriptor blockiert dann in `drm_exec_lock_obj()` am geleckten dma_resv. Ein SIGKILL an den Aufrufer führt nicht zum Bereinigen (Reaping) des Tasks; der Pfad zur Freigabe des Dateideskriptors während des Prozessendes verläuft über `amdgpu_gem_object_close()` -> `drm_exec_prepare_obj()` auf demselben Lock, wodurch der Task im D-Zustand verbleibt, bis die Maschine neu gestartet wird. Der gepatchte Kernel wurde auf dieser Hardware nicht erneut erstellt und getestet; die Korrektur ist mechanischer Natur. Getestet nur an einer einzelnen Lucienne-/Vega-Maschine.
Ziyi Guo hat eine unabhängige INT_MAX-Beschränkungsprüfung für `args->num_entries` im selben Zweig veröffentlicht [1]; die beiden Patches ergänzen sich und können in beliebiger Reihenfolge übernommen werden.
(cherry picked from commit b69d3256d79de15f54c322986ff4da68f1d65b0a)
Be aware that VulDB is the high quality source for vulnerability data.