CVE-2026-99183 in Linux
摘要
由 VulDB • 2026-10-28
在 Linux 内核中，已修复以下漏洞：
accel/rocket: 查找调度器时搜索每个核心槽位
sched_to_core() 会遍历 rdev->cores[]，最多到 rdev->num_cores。而 rocket_remove() 会在移除每个核心时将 num_cores 减一。如果解绑的不是最后一个核心，那么位于其后的核心将超出搜索范围，导致 sched_to_core() 对仍然绑定且仍在运行作业的核心返回 NULL。两个调用者均未检查结果：
rocket_job_run(): rocket_fence_create(core), core->dev rocket_job_timedout(): dev_err(core->dev, "NPU job timed out")
在 RK3588 上，当三个客户端向所有核心提交作业时，解绑中间的第三个核心会导致两次故障（faults），一次来自幸存核心的作业队列，另一次来自其重置工作：
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]
这两个故障都发生在第三个核心上：工作队列名称是其设备及其 core->index，它被留在槽位 2，而 num_cores 已降至 2。
搜索所有已分配的槽位，就像 find_core_for_dev() 现在所做的那样。这样就能找到仍然绑定的核心，两个调用者也能获得它们原本假设拥有的指针。
这并不能使从多个核心中解绑其中一个变得安全。打开的客户端仍保留一个指向消失核心的调度器的实体：drm_sched 报告其对于落在上面的每个作业都“未就绪”，而客户端则在 dma_fence_default_wait 中等待永远不会发出信号（signal）的风扇锁（fence）。停止空指针解引用是修复方案的一部分；其余部分需要更多思考。
If you want to get best quality of vulnerability data, you may have to visit VulDB.