CVE-2026-80919 in Linux
要約
〜によって VulDB • 2026年09月09日
Linuxカーネルにおいて、以下の脆弱性が修正されました：
drm/amdgpu: amdgpu_devcoredump_formatにおける再帰的なww_mutexの取得を修正する
ハングしたジョブからIB（Indirect Buffer）の内容をダンプする場合、amdgpu_devcoredump_format()はamdgpu_vm_lock_by_pasid()を通じてVMルートPDのプロテクションリソースを取得し、その後、各IBについてそのIBを支えるBOに対してamdgpu_bo_reserve()を呼び出します。両方のプロテクションリソースはreservation_ww_class_mutexオブジェクトであり、いずれもww_acquire_ctxを使用していないため、lockdepが警告を発します：
WARNING: possible recursive locking detected -------------------------------------------- kworker/u128:0 is trying to acquire lock: ffff88838b16e1f0 (reservation_ww_class_mutex){+.+.}-{4:4},
at: amdgpu_devcoredump_format+0x1594/0x23f0 [amdgpu]
but task is already holding lock: ffff8882f82681f0 (reservation_ww_class_mutex){+.+.}-{4:4},
at: amdgpu_devcoredump_format+0x1594/0x23f0 [amdgpu]
Possible unsafe locking scenario: CPU0 ---- lock(reservation_ww_class_mutex); lock(reservation_ww_class_mutex);
*** DEADLOCK *** May be due to missing lock nesting notation
Workqueue: events_unbound amdgpu_devcoredump_deferred_work [amdgpu]
Call Trace: __ww_mutex_lock.constprop.0 ww_mutex_lock amdgpu_bo_reserve amdgpu_devcoredump_format+0x1594 [amdgpu]
amdgpu_devcoredump_deferred_work+0xea [amdgpu]
2つのプロテクションリソースはキャプチャされたトレース内の異なるBOに存在するため、このスプラット（警告出力）はlockdepによる正しさの警告であり、実際に観測されたデッドロックではありません。しかし、IB BOがルートPDとdma_resvを共有している場合（常に有効なケース、amdgpu_vm_is_bo_always_valid()参照）、これは実際の自己デッドロックになります： amdgpu_bo_reserve(abo)はチケットなしで同じww_mutexを再取得し、永久にブロックします。amdgpu.gpu_recovery=0の場合、タイムアウトハンドラは約2秒ごとに再発火し、各呼び出しがこのスプラットを生成するため、カーネルリングバッファが埋め尽くされてしまいます。
現在、amdgpu_vm_lock_by_pasid()はdrm_execコンテキストを取得するようになったため、IBのダンプ処理を別のヘルパー関数に移動させ、ルートPDとすべてのIB BOを単一のdrm_execチケットで同時にロックするようにしました。DRM_EXEC_IGNORE_DUPLICATESフラグにより、dma_resvを共有しているIB BO（例：常に有効なBOや、同じBOによって支えられた2つのIBなど）が処理されます。これにより、すべてのロックは1つのww_acquire_ctxの下でのトップレベルの取得となり、再帰的なww_mutexの問題は解消されました。また、per-IBごとのamdgpu_bo_reserve()/amdgpu_bo_unref()という一連の操作（特にamdgpu_bo_reserve()の失敗パスにおけるBO参照カウントリーク）も削除されました。
(cherry picked from commit d6bf4242731219ee08ce54c365631e395486651e)
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.