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 で3つのコアのうち中央のコアをアンバインドし、かつ3つのクライアントがすべてにジョブを送信している場合、2回フォールトが発生します。1回は生存したコアのジョブキューから、もう1回はそのリセット作業（reset work）からのものです：
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]
これら両方のケースで問題となるのは3番目のコアです。ワークキューの名前はデバイスの名前と core->index であり、num_cores が2に減少したにもかかわらず、そのコアはスロット2に残されたままでした。
find_core_for_dev() が現在行っているように、割り当てられたすべてのスロットを探索します。これにより、まだバインドされているコアが検出され、両方の呼び出し元は既に自分たちが持っているものと想定しているポインタを取得できます。
ただし、これは複数のコアのうち1つのアンバインドを安全にするものではありません。オープンなクライアントは、消えたコアのスケジューラを指すエンティティを保持したままになります：drm_sched はそこに到着するすべてのジョブに対して「準備できていない」として報告し、クライアントは決してシグナルを受信しないフェンスのために dma_fence_default_wait で待機します。NULL ポインタ参照（null-ptr-deref）の停止が修正に属すべき部分であり、残りの問題はさらに検討が必要です。
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.