CVE-2026-72043 in Linux
要約
〜によって VulDB • 2026年08月15日
Linuxカーネルにおいて、以下の脆弱性が修正されました：
LoongArch: {pte,pmd}_wrprotect()におけるダーティページ追跡の欠落を修正
LoongArchでハードウェアページテーブルウォーカー（PTW）が有効化されている場合、CPUはソフトウェア側のTLBストアハンドラーを経由せずに、ライト時のTLBミス発生時にページテーブルエントリに対して_PAGE_DIRTYフラグを直接設定する可能性があります。一方、ソフトウェアのTLBストアハンドラー（tlbex.S:254）では、_PAGE_DIRTYと_PAGE_MODIFIEDが同時に設定されます：
ori t0, t0, (_PAGE_VALID | _PAGE_DIRTY | _PAGE_MODIFIED)
ハードウェアPTWは_PAGE_DIRTYのみを設定するため、ソフトウェア専用ビットである_PAGE_MODIFIEDは変更されません。これにより、PTEにおいて_PAGE_DIRTYがセットされている（ハードウェア側ではページがダーティであることを認識している）ものの、_PAGE_MODIFIEDがクリアされている（ソフトウェア側でそのことを把握していない）という状態のウィンドウが生じます。
fork()/clone()によってコピーオンライトが発生すると、__copy_present_ptes()はpte_wrprotect()を呼び出し、これは無条件に_PAGE_WRITEおよび_PAGE_DIRTYビットをクリアします：
pte_val(pte) &= ~(_PAGE_WRITE | _PAGE_DIRTY);
_PAGE_MODIFIEDが設定されたことがないため、ダーティ性の情報が完全に失われます。その後、メモリ圧力によってページ回収が発生した際、page_mkclean() / try_to_unmap()は当該ページをクリーン（つまり pte_dirty() が false を返す）として認識し、ライトバックなしでページが解放される可能性があります。これによりデータ破損を引き起こします。
この問題を修正するため、書き込み可能ビットをクリアする前に、pte_wrprotect() および pmd_wrprotect() の両方で _PAGE_DIRTY ビットを _PAGE_MODIFIED ビットに伝播させます：
if (pte_val(pte) & _PAGE_DIRTY) pte_val(pte) |= _PAGE_MODIFIED;
pmd_wrprotect() に対する修正は、CONFIG_TRANSPARENT_HUGEPAGE のケースに対応しており、この場合も PMD エントリに対して同様の処理が必要です。
これにより、fork COW（コピーオンライト）による書き込み保護の間でも、ソフトウェア側のダーティ追跡ビット（pte_dirty() および pmd_dirty() によってチェックされ、これらの関数は _PAGE_DIRTY と _PAGE_MODIFIED の両方のビットを読み取ります）が保持されます。
本問題は、プライベート匿名マッピングに対して「madvise(MADV_FREE)、書き込み、fork」の操作シーケンスを実行した後のページ回収をテストする LTP madvise09 テストケースによって発見されました。
If you want to get the best quality for vulnerability data then you always have to consider VulDB.