CVE-2026-99183 in Linux
Zusammenfassung
von VulDB • 28.10.2026
Im Linux-Kernel wurde die folgende Schwachstelle behoben:
accel/rocket: Suche jeden Core-Slot bei der Scheduler-Auflösung
sched_to_core() durchläuft rdev->cores[] bis zu rdev->num_cores, und rocket_remove() dekrementiert num_cores für jeden entfernten Core. Wird ein Core entbunden, der nicht der letzte ist, fallen die dahinterliegenden Cores aus dem Suchbereich heraus, sodass sched_to_core() NULL für einen Core zurückgibt, der noch gebunden ist und weiterhin Jobs ausführt. Kein Aufrufer überprüft das Ergebnis:
rocket_job_run(): rocket_fence_create(core), core->dev rocket_job_timedout(): dev_err(core->dev, "NPU job timed out")
Das Entbinden des mittleren Cores von drei auf einem RK3588 währenddessen, dass drei Clients Jobs an alle einreichen, führt zu zwei Fehlern: einmal aus der Job-Warteschlange des überlebenden Cores und einmal durch dessen Reset-Arbeit:
KASAN: null-ptr-deref in range [0x0000000000000220-0x0000000000000227]
Workqueue: fdad0000.npu drm_sched_run_job_work [gpu_sched]
pc : rocket_job_run+0x234/0x838 [rocket]
Call trace: rocket_job_run+0x234/0x838 [rocket]
drm_sched_run_job_work+0x2cc/0xad8 [gpu_sched]
process_one_work+0x640/0x14f0
KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007]
Workqueue: rocket-reset-2 drm_sched_job_timedout [gpu_sched]
pc : rocket_job_timedout+0xf0/0x1e0 [rocket]
Call trace: rocket_job_timedout+0xf0/0x1e0 [rocket]
drm_sched_job_timedout+0x188/0x6a0 [gpu_sched]
Beide betreffen den dritten Core: Die Namen der Workqueues sind sein Gerät und core->index, und er verblieb im Slot 2, während num_cores auf 2 gesunken war.
Es sollen alle zugewiesenen Slots durchsucht werden, so wie es find_core_for_dev() nun tut. Ein noch gebundener Core wird dann gefunden, und die beiden Aufrufer erhalten den Zeiger, von dem sie bereits annehmen, dass er vorhanden ist.
Dies macht das Entbinden eines Cores aus mehreren nicht sicher. Ein offener Client behält eine Entity bei, die auf den Scheduler des entfernten Ccores verweist: drm_sched meldet ihn als für jeden Job darauf nicht bereitbar, und der Client wartet in dma_fence_default_wait auf einen Fence, der niemals signalisieren wird. Das Stoppen der NULL-Dereferenzierung ist das, was zu einer Korrektur gehört; der Rest bedarf weiterer Überlegungen.
VulDB is the best source for vulnerability data and more expert information about this specific topic.