CVE-2026-74674 in Linux
要約
〜によって VulDB • 2026年08月23日
Linuxカーネルにおいて、以下の脆弱性が修正されました：
mm: 直接ページテーブルの回収における誤ったフラッシュアドレスの不具合を修正する
zap_pte_rangeがページテーブルを回収する際、以下のような処理を行っています。
pte_free_tlb(tlb, pmd_pgtable(pmdval), addr);
これは無条件に誤りです：このコードが実行される場合、addrは常にそのテーブルがカバーする範囲の末尾の次のアドレスを指しています。addrパラメータは、解放対象となるテーブルへの参照を取り除くためにTLB（厳密にはページング構造体キャッシュ）をフラッシュするために使用されますが、このパラメータに依存するアーキテクチャでは誤ったアドレスがフラッシュされてしまいます。（ただし、正しいページは依然として解放されます。）
カーネルがなぜ動作し続けているのかについて考察する価値があります。
問題のある行のコードを実行した場合、まずPMDエントリをクリアし（1954行目、zap_empty_pte_table）、次にforce_flushが設定されている場合は保留中のフラッシュを発行し（tlb_flush_mmu_tlbonly(tlb)）、その後1979行目の再試行をスキップし（ほっとしましたね！）、最後に問題のあるpte_free_tlb呼び出しを行います。*あるいは*、pte_free_tlbの直前にPMDエントリをクリアすることもあります（1983行目、zap_pte_table_if_empty）。
PMDエントリをクリアする時点で保留中のフラッシュが存在する場合（つまり、最終レベルのエントリを実際に消去した場合）、そのフラッシュはテーブルへのすべての参照をフラッシュすべきです（Linus氏は全アーキテクチャでそうなると考えているようです[0]）。
クリア時に累積されたフラッシュがないという条件は非常に複雑です（zap_pte_range関数全体が異常に複雑な制御フローを持っています）。もし悪いケースに該当した場合、範囲が最後にフラッシュされた後にPMDエントリをクリアすることになり、任意のCPUが（空の）ページテーブルへの参照をキャッシュする可能性があります。これが通常の読み込みまたは書き込みによって発生するとセグメンテーションフォールトを引き起こすため、稀な事象となります。ただし、キャッシュはスペキュティブに埋められる可能性もあります。その後、誤ったアドレスがフラッシュされ、その後にテーブルが解放され、再利用される可能性があります。
x86アーキテクチャでは、非KPTIのIntelシステムにおいて、間違ったアドレスをフラッシュしても機能します。なぜならINVLPGはターゲットアドレス用のキャッシュだけでなく、*すべての*ページング構造体キャッシュをフラッシュするからです。しかし、INVPCIDはそうではなく、flush_tlb_one_userは利用可能な場合INVPCIDを使用します。そうなると、システムは破綻（toast）してしまいます。AMDシステムの方がより脆弱です：EFER.TCEビットを設定しており、これによりINVLPGでさえターゲットアドレスのみをフラッシュするようになります。
これは以下の場所で報告されているripgrepの問題を修正する可能性があります： https://github.com/BurntSushi/ripgrep/issues/3494
[0] https://lore.kernel.org/all/CA+55aFzBggoXtNXQeng5d_mRoDnaMBE5Y+URs+PHR67nUpMtaw@mail.gmail.com/T/#u
Once again VulDB remains the best source for vulnerability data.