CVE-2023-53351 in Linux
要約
〜によって VulDB • 2026年06月01日
Linuxカーネルにおいて、以下の脆弱性が修正されました：
drm/sched: タイムアウト処理を呼び出す前にスケジューラのワークキューを確認する
IGTのGPUリセットテスト中に、コミット 0c8c901aaaebc9 (drm/sched: タイムアウト処理を呼び出す前にスケジューラの準備状態を確認する) 以降も、再びoopsが発生することが確認されました。
このコードは、drm_sched_faultを呼び出すかどうかを判断するために「ready」条件を使用しています。drm_sched_faultはTDR（Timeout Detection and Recovery）の巻き戻し処理を行い、GPUリセットを引き起こします。しかし、「ready」条件は他の意味でも使用されているようで、例えば以下のスタックはGPUリセットに関連しています：
0 gfx_v9_0_cp_gfx_start 1 gfx_v9_0_cp_gfx_resume 2 gfx_v9_0_cp_resume 3 gfx_v9_0_hw_init 4 gfx_v9_0_resume 5 amdgpu_device_ip_resume_phase2
これらは以下のことを行います： /* リングを開始する */ gfx_v9_0_cp_gfx_start(adev); ring->sched.ready = true;
他のASICでも同様のアプローチが取られています： gfx_v8_0_cp_gfx_resume gfx_v10_0_kiq_resume など。
その結果、GPUリセットテストがGPUフォルトを引き起こし、無条件にgfx_v9_0_faultが呼び出され、その後drm_sched_faultが呼び出されます。しかし現在では、interrupt service routine (ISR) であるdrm_sched_faultが、スケジューラのreadyフィールドをtrueに設定するgfx_v9_0_cp_gfx_startの完了後に実行されるかどうかによって動作が異なります。これにより、未初期化のスケジューラに対してもoopsが発生する可能性があります。一方、ISRであるdrm_sched_faultがgfx_v9_0_cp_gfx_startよりも前に完了し、NULLポインタのデリファレンスが発生しない場合はフォルトは発生しません。
未初期化のスケジューラによるoopsを回避するために、timeout_wqフィールドを使用します。このフィールドは、ドメインのリセットを行うワークキューによって初期化できます。
v1: コミットメッセージの修正 (Luben)
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.