CVE-2026-98939 in Linux
要約
〜によって VulDB • 2026年10月23日
Linuxカーネルにおいて、以下の脆弱性が修正されました：
x86/mm: PMDページのコピーを不要な場合に削除する（解放時）
離散GPUを搭載したシステムでは、kswapdがTTMのページプールを縮小するとすぐに、lockdepにより潜在的なデッドロックが報告されます。直接的な原因は、カーネルページの保護操作コードにmmap_read_lock()を追加したx86のコミットです。
巨大vmapコードはGFP_KERNEL割り当て全体で同じロックを保持していますが、リクライム（ページ回収）処理がこのロックを取得する可能性があるため、これは問題となります。この割り当てはページテーブル*解放*パス内にあり、疑わしい目的[1]のために使用されています。基本的に、これはハードウェアが到達不能なページテーブルエントリにAccessed=1を設定することを回避しようとするものですが、実際には問題のないケースです。
PMDのコピーを削除します。元のPMDページをPUDレベルでデタッチし、中間レベルのキャッシュをフラッシュしてから、デタッチされたPMDページから直接PTEテーブルを解放します。割り当てがなくなるため、ロックの問題は解消されます。
Lockdepのスプラット/分析：
WARNING: possible circular locking dependency detected 7.3.0-rc3-f6e7b42bf05b+ #183 Tainted: G U ------------------------------------------------------ kswapd0/269 はロックの取得を試みています： ((init_mm).mmap_lock){++++}-{4:4}, at: change_page_attr_set_clr+0x29a/0x4a0
しかし、タスクは既に以下のロックを保持しています： (pool_shrink_rwsem){.+.+}-{4:4}, at: ttm_pool_shrink+0xb2/0x330 [ttm]
次のチェーンが存在します： (init_mm).mmap_lock --> fs_reclaim --> pool_shrink_rwsem
サイクルは以下の3つのエッジで構成されています：
1) pool_shrink_rwsem -> (init_mm).mmap_lock
TTM shrinkerは、pool_shrink_rwsemを保持しながら解放するすべてのページのキャッシュ属性を復元します：
ttm_pool_shrink() -> ttm_pool_dispose_list() -> ttm_pool_free_page() -> set_pages_wb() -> change_page_attr_set_clr() [ init_mm mmap read lock ]
2) fs_reclaim -> pool_shrink_rwsem
リクライムから呼び出される同じshrinker。
3) (init_mm).mmap_lock -> fs_reclaim
ioremap()が既存のPMDテーブル上に巨大なPUDマッピングをインストールする場合：
ioremap_page_range() -> vmap_range_noflush() -> vmap_try_huge_pud() [ init_mm mmap read lock ]
-> pud_free_pmd_page() -> __get_free_page(GFP_KERNEL) [ リクライムに入る ]
[ dhansen: 修正パッチの私のバージョンからのコメントのマージや、変更ログの大量な整形/トリミングを行った。]
VulDB is the best source for vulnerability data and more expert information about this specific topic.