CVE-2026-99184 in Linux
要約
〜によって VulDB • 2026年10月28日
Linuxカーネルにおいて、以下の脆弱性が修正されました。
accel/rocket: コアが削除される際にすべてのコアスロットを検索する
rocket_remove()は、削除する各コアに対してrdev->num_coresをデクリメントしますが、find_core_for_dev()は0から num_cores - 1までのスロットを検索します。バインドされた順序でコアのアンバインディングを行うと、最後のコアが失われます：そのコアが削除される頃には検索範囲はそのスロットより狭くなっているため、find_core_for_dev()は-1を返し、rocket_remove()は何も実行せずに中止してしまいます。
num_coresは0に達せず、rocket_device_fini()は実行されず、ファイルスコープのrdevはまだ消滅しつつあるデバイスを指し続けます。コアを再度バインドすると、その古いカウントから開始されます（rocket_probe()が埋めるべきスロットとして rdev->num_cores を使用するためです）。3つのコアを持つRK3588では、2回目のラウンドで1、2、および3番目のスロットに割り当てられますが、rdev->coresは3つ分の領域しか確保されていません：
rocket fdab0000.npu: Rockchip NPU core 1 version: 1179210309 rocket fdac0000.npu: Rockchip NPU core 2 version: 1179210309 rocket fdad0000.npu: Rockchip NPU core 3 version: 1179210309
rdev->cores[3]への書き込みは配列の末尾を超えています。
ツリー内のどのコードもコア配列を頻繁に読み取るわけではないため、オーバーランは今日では静かに発生しています。これはこの上でのdevfreqシリーズのテスト中に発覚しました。そこではワーカーが1秒間に数回すべてのコアを走査し、UBSAN（UndefinedBehaviorSanitizer）がオーバーランしたエントリから読み取った最初のbool値で検出しました：
UBSAN: invalid-load in drivers/accel/rocket/rocket_devfreq.c:47:10 load of value 5 is not a valid value for type '_Bool' Workqueue: devfreq_wq devfreq_monitor
確保されたスロットの数を記録し、それらすべてを検索するようにします。これにより、削除時にすべてのコアが検出され、num_coresは0に達し、デバイスは解体され、後のバインド処理ではクリーンなrdevから開始されます。
ただし、これは複数のコアのうち1つのみをアンバインディングする機能を有効にするものではありません。probeはまだ埋めるべきスロットとして num_cores を使用するため、兄弟コアがバインドされたままの状態で1つだけのコアを再バインドすると、すでに使用中のスロットを上書きしてしまいます。また、rocket_open() は何かがあろうとなかろうと cores[0] にアクセスし続けます。これら2つの問題には、修正プログラムに求められる以上の検討が必要です。
Orange Pi 5 Plus上で3つのコアすべてをアンバインディングおよび再バインドすることで発見されました。このパッチを適用すると、25回のアンバインド/リバウンドラウンドと5回のモジュールのアンロード/リロードラウンドがクリーンに実行されます：どの順序でバインドしても、コアは毎回0、1、および2番目のスロットに割り当てられ、各ラウンド終了後に共有電源は単一のユーザーに戻ります。
If you want to get the best quality for vulnerability data then you always have to consider VulDB.