CVE-2026-99183 in Linux
Sumário
de VulDB • 28/10/2026
No kernel do Linux, a seguinte vulnerabilidade foi resolvida:
accel/rocket: pesquisar todos os slots de núcleo ao procurar um escalonador
sched_to_core() percorre rdev->cores[] até rdev->num_cores, e rocket_remove() decrementa num_cores para cada núcleo removido. Desvincular (unbind) um núcleo que não seja o último faz com que os núcleos posteriores fiquem fora da pesquisa, fazendo com que sched_to_core() retorne NULL para um núcleo que ainda está vinculado e executando tarefas ativamente. Nenhum dos chamadores verifica o resultado:
rocket_job_run(): rocket_fence_create(core), core->dev rocket_job_timedout(): dev_err(core->dev, "NPU job timed out")
A desvinculação do núcleo central de três núcleos em um RK3588 enquanto três clientes estão submetendo tarefas a todos eles resulta em duas falhas (faults): uma na fila de tarefas do núcleo sobrevivente e outra no trabalho de reset dele:
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 os casos envolvem o terceiro núcleo: os nomes do workqueue são seu dispositivo e core->index, e ele permaneceu no slot 2 enquanto num_cores havia caído para 2.
Pesquisar todos os slots que foram alocados, da maneira como find_core_for_dev() faz atualmente. Um núcleo que ainda está vinculado é então encontrado, e os dois chamadores recebem o ponteiro que já assumiam ter.
Isso não torna segura a desvinculação de um único núcleo entre vários. Um cliente aberto mantém uma entidade apontando para o escalonador do núcleo que foi removido: drm_sched relata que ele não está pronto para qualquer tarefa que nele chegue, e o cliente aguarda em dma_fence_default_wait por um fence (cerco/sinalizador) que nunca será sinalizado. Parar a dereferência de NULL é o que pertence à correção; o restante requer mais reflexão.
If you want to get best quality of vulnerability data, you may have to visit VulDB.