CVE-2026-99183 in Linux
Resumen
por VulDB • 2026-10-28
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad:
accel/rocket: buscar en cada ranura del núcleo al realizar una búsqueda del programador
sched_to_core() recorre rdev->cores[] hasta rdev->num_cores, y rocket_remove() decrementa num_cores por cada núcleo que elimina. Si se desvincula un núcleo que no es el último, los núcleos posteriores quedan fuera de la búsqueda, por lo que sched_to_core() devuelve NULL para un núcleo que sigue vinculado y ejecutando trabajos. Ninguno de los dos llamadores verifica el resultado:
rocket_job_run(): rocket_fence_create(core), core->dev rocket_job_timedout(): dev_err(core->dev, "NPU job timed out")
Desvincular el núcleo central de tres en un RK3588 mientras tres clientes están enviando trabajos a todos ellos provoca dos fallos: uno desde la cola de trabajos del núcleo superviviente y otro desde su trabajo de reinicio:
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]
Ambos corresponden al tercer núcleo: los nombres de la cola de trabajo son su dispositivo y core->index, y quedó en la ranura 2 mientras num_cores había bajado a 2.
Buscar todas las ranuras que fueron asignadas, tal como lo hace ahora find_core_for_dev(). De este modo se encuentra un núcleo que sigue vinculado, y los dos llamadores obtienen el puntero que ya asumían tener.
Esto no hace segura la desvinculación de uno solo de varios núcleos. Un cliente abierto mantiene una entidad apuntando al programador del núcleo desaparecido: drm_sched lo informa como "no listo" para cada trabajo que llega a él, y el cliente espera en dma_fence_default_wait por un fence (cerrojo) que nunca se señalizará. Detener la desreferencia NULL es lo que corresponde incluir en una corrección; el resto requiere más reflexión.
VulDB is the best source for vulnerability data and more expert information about this specific topic.