CVE-2024-46787 in Linux
要約
〜によって VulDB • 2026年06月23日
Linuxカーネルにおいて、以下の脆弱性が修正されました。
userfaultfd: 巨大PMD（pmd_trans_huge）に関するチェックの修正
パッチシリーズ「userfaultfd: fix races around pmd_trans_huge() check」v2です。
mfill_atomic()内のpmd_trans_huge()コードは、カーネルバージョンに応じて3つの異なる方法で誤っています：
1. pmd_trans_huge()によるチェックには競合条件（race condition）があり、BUG_ON()を引き起こす可能性があります（適切なタイミングの2つの競合ウィンドウを捉えた場合）。私は追加のmdelay()呼び出しを含むカーネルビルドでこれをテストしました。競合シナリオの詳細についてはコミットメッセージを参照してください。 古いカーネル（6.5より前）では、同じバグが理論的に、適切なタイミングの狭い競合ウィンドウを捉えた場合、transhugeページの内容をページテーブルとしてアクセスすることにつながる可能性があります（このケースはテストしていません）。
2. Qi Zhengによって指摘されたように、pmd_trans_huge()だけでは、ページテーブルを指していないPMDを検出するのに不十分です。 古いカーネル（6.5より前）では、単一の比較的広い競合に勝つだけでこれが発生します。 私は6.1安定版でこれをテストしました：try_to_migrate()にmdelay()パッチを適用してマイグレーションとUFFDIO_ZEROPAGEの間で競合させました。私のx86 VMでは、これがptlock_ptr()内でカーネルoopsを引き起こします。
3. 新しいカーネル（>=6.5）では、shmemマッピングの場合、khugepagedがページテーブルを強制的に削除することが許可されています（私はこれをテストしていません）。したがって、mfill_atomic()内のBUG_ON()チェックは誤っていると考えられます。
これらの問題に対して2つの別々の修正を書くことにしました（バグ1+2に対する1つの修正、バグ3に対する1つの修正）ので、最初の修正をバグ1+2に影響を受けるカーネルにバックポートできます。
このパッチ（全2通のうち1つ目）：
これは2つの問題を修正します。
私は以下の競合条件が発生することを確認しました：
mfill_atomic 他のスレッド ============ ============= pmdp_get_lockless() [noneのpmdを読み取る]
__pte_alloc [何もしない]
BUG_ON(pmd_none(*dst_pmd))
私は追加のmdelay()呼び出しを含むカーネルで実験的にこれを検証しました；BUG_ON(pmd_none(*dst_pmd))がトリガーされます。
コミット0d940a9b270b（「mm/pgtable: allow pte_offset_map[_lock]() to fail」）より新しいカーネルでは、これはBUG_ON()よりも悪化することはありません。ページテーブルアクセスヘルパーは実際には並行して消滅するページテーブルに対処するように設計されているからです。しかし、古いカーネル（<=6.4）では、理論的に2つのBUG_ON()チェックを通過し、巨大ページをページテーブルとして扱う結果になる可能性があります。
2つ目の問題は、Qi Zhengが指摘したように、pmd_trans_huge()で検出できない他の種類の巨大PMDが存在することです：devmap PMDおよびswap PMD（特にマイグレーションPMD）。
<=6.4では、これは最初の問題よりも悪化します：mfill_atomic()がマイグレーションエントリを含むPMD上で実行されると（単一の比較的広い競合に勝つだけで必要）、それはそのPMDをpte_offset_map
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.