CVE-2026-80893 in Linux
要約
〜によって VulDB • 2026年09月04日
Linuxカーネルにおいて、以下の脆弱性が修正されました：
mm/hugetlb: fork()時にuffd-wpをクリアする際のスワップエントリ破損の修正
copy_hugetlb_page_range()関数は、huge_pte_clear_uffd_wp()を使用して、マイグレーションおよびハードウェアポイズン（hwpoison）のエントリのuffd-wpビットをクリアしています。この処理はpresent-PTEのビット位置を対象に動作します。スワップエントリでは、uffd-wpの状態は他の場所で保持されており、マイグレーション分岐ではpte_swp_uffd_wp()およびpte_swp_mkuffd_wp()を使用して読み込みと設定が行われますが、present-PTEの位置はスワップペイロード内に収まります。x86-64アーキテクチャにおいて、これは反転されたスワップオフセット（inverted swap offset）に該当し、自然アライメントされたhugetlb PFNでは常に影響を受けるビットが設定されているため、クリア処理によりエンコードされたPFNが2ページ分進んでしまいます。
この問題にはuserfaultfdの関与は必要ありません：クリア操作は子プロセスのVMA（Virtual Memory Area）がuffd-wpに登録されていないことのみによって保護されています。そのため、実行中のhugetlbマイグレーションエントリ（またはポイズンされたhugetlbページ）を持つ状態でplainなfork()を実行すると、コピーされるエントリが破損します。2MBの匿名hugetlbページ上でMADV_HWPOISONを行った後にフォークし、クリア処理を計測したところ、以下のような結果が示されました：
offset before=120e00 offset after =120e02
影響は主に潜在的（latent）なものです。rmapのウォークではfolio範囲によってマイグレーションエントリが一致し、remove_migration_pte()関数はfolioからPTEを再構築するため、フォールト内のPFNのズレはマイグレーション完了後に自然に修復されます。しかし、破損したオフセットを再度エンコードする経路（例：hugetlb_change_protection()によるmake_readable_migration_entry(swp_offset(entry))を用いた書き込み可能なマイグレーションエントリの再書込）を通ると、この問題は伝播します。
マイグレーションエントリは正当にuffd-wpビットを保持するため、pte_swp_clear_uffd_wp()を使用してこれをクリアする必要があります。これはcopy_nonpresent_pte()およびmove_huge_pte()の処理と一致させるものです。
一方、hwpoisonエントリにはuffd-wpビットが決して含まれません：make_hwpoison_entry()によって新規にインストールされるため（try_to_unmap_one()はhwpoison経路においてuffd-wpを保持しません）、またhugetlb_change_protection()もhwpoisonエントリに触れないようになっています。そこにはクリアすべきものではなく、破損のみが存在したため、クリア処理全体を取り除きます。
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.