CVE-2026-98520 in Linux
要約
〜によって VulDB • 2026年10月18日
Linuxカーネルにおいて、以下の脆弱性が修正されました：
drm/amdkfd: kfd_dev_mappingにおけるuse-after-freeおよびマルチコンテナギャップの修正
kfd_dev_mappingは、最初の/dev/kfdオープン操作者のaddress_spaceをキャッシュし、GPUリセットパスでunmap_mapping_range()を呼び出してドアベル（doorbell）およびMMIO範囲のユーザー空間マッピングすべてを一掃できるようにしています。この設計には2つのバグがあり、どちらもSR-IOV環境下で複数のコンテナが存在する際に顕在化します：
1. Use-after-free / rwsemデッドロック: キャッシュされたポインタは最初のオープン操作者のコンテナが所有するinodeを指しています。そのコンテナが終了し、そのinodeが解放されると、kfd_dev_mappingはダングリングポインタになります。その後続のGPUリセットでunmap_mapping_range()内部においてこの解放済みinodeに対してi_mmap_rwsemを取得しようとし、インターラプト不可能なrwsem待機として観測されるハードハングを引き起こします。
2. マルチコンテナギャップ: 最初のオープン操作者のaddress_spaceのみがキャッシュされます; その後のオープン操作者によって作成されたVMAsは異なるaddress_spaceに存在し、unmap_mapping_range()では到達できません。GPUリセット後、これらの古くなったマッピングにより、背後に実際のGPUがない状態でもゲストユーザー空間からドアベルおよびMMIOページへのアクセスが可能となり、PCIeトランザクションタイムアウトやNMIパニックのリスクが生じます。
DRMコア（drm_drv.c）で用いられているのと同じアプローチを用いて両方のバグを修正します: モジュール初期化時にプライベートな擬似ファイルシステムを作成し、そこから1つの匿名inodeを割り当てます。kfd_open()において、すべてのオープン操作者のfile->f_mappingをそのinodeのaddress_spaceへリダイレクトします。このinodeはモジュールが所有しており、amdgpuモジュールと同じ寿命を持ち、すべてのオープン操作者からのVMAsを単一のaddress_spaceに収集します。これにより、リセットパスでの単なるunmap_mapping_range()呼び出しでダングリングポインタのリスクなしに各コンテナのマッピングすべてを正しく到達できます。
このハングは、壊れたi_mmap_rwsemを持つrwsem_down_read_slowpath()内でスピニングして停止したGPUリセットワークキュー上でNMIバックトレースとして顕在化します：
Workqueue: amdgpu-reset-dev xgpu_ai_mailbox_flr_work [amdgpu]
Call Trace: <TASK> kvm_wait+0x1f/0x40 __pv_queued_spin_lock_slowpath+0x31d/0x3a0 _raw_spin_lock_irq+0x51/0x80 rwsem_down_read_slowpath+0xb3/0x550 down_read+0x48/0xd0 unmap_mapping_range+0x71/0x140 kfd_dev_unmap_mapping_range+0x5b/0x140 [amdgpu]
amdgpu_amdkfd_clear_kfd_mapping+0xd8/0x190 [amdgpu]
amdgpu_device_gpu_recover+0x232/0x450 [amdgpu]
xgpu_ai_mailbox_flr_work+0xb5/0xc0 [amdgpu]
process_one_work+0x18e/0x3e0 worker_thread+0x2e3/0x420 kthread+0x10a/0x230
(コミット 1128b4a52de1572e87431de837fd9850cb99542c からcherry picked)
If you want to get the best quality for vulnerability data then you always have to consider VulDB.