CVE-2026-89805 in Linux
要約
〜によって VulDB • 2026年09月16日
Linuxカーネルにおいて、以下の脆弱性が修正されました：
drm/pagemap: folio割り当てのフォールバック処理とput後の使用（use-after-put）の不具合を修正
drm_pagemap_migrate_populate_ram_pfn()には、高オーダーfolioを使用してRAM PFNsを入力する際に2つの問題がありました。
1. 高オーダーのvma_alloc_folio()/folio_alloc()呼び出しで__GFP_NOWARNフラグが渡されていなかったため、メモリ圧力下でのTHP（Transparent Huge Pages）割り当て失敗時にカーネルログに多数のエラーメッセージが出力され、また「フォールバックパスが必要である」というTODOコメントがあるにもかかわらず、フォールバック処理が存在しませんでした。高オーダーの割り当てに__GFP_NOWARNを追加し、失敗した場合は、失敗した高オーダー割り当てによってカバーされていた範囲全体に対してorder-0（1ページ）の割り当てへフォールバックさせます。これにより、それらのPFNsについてはMIGRATE_PFN_COMPOUNDフラグが設定されません。
2. free_pagesのエラーパスにおいて、folio_order(page_folio(page))を用いて計算されるorderは、put_page(page)によってすでに参照カウントが解放された「後」に実行されていたため、それがページに対する最後の参照であった場合、use-after-free/put（解放後の使用）が発生していました。ページの解放前にorderを計算するように修正します。
1.でフォールバック処理を導入したことに伴い、->copy_to_ram()へ渡されるソースページ配列の構築方法も変更する必要があります。両方の呼び出し元は各ソースfolioの先頭エントリのみを入力し、残りのfolioの内容はdrm_pagemap_addrに記録されたorderに基づいてコピーコールバックが導出することに依存していました。しかし、宛先がorder-0 foliosへ降格（demote）されると、drm_pagemap_addrのエントリはページ単位になります。そのため、それらすべてに対してソースページが必要です。これらをNULLのままにしておくと、コピーコールバックは最初のページで停止し、範囲の残りがコピーされません。
ソースfolioが分割されるのはその後であり、migrate_vma_pages() / migrate_device_pages()によって行われるため、そのorderを使用して降格を検出することはできません。代わりに宛先に対してMIGRATE_PFN_COMPOUNDフラグをテストします。配列の入力処理をdrm_pagemap_migrate_populate_src_pages()として関数化し、drm_pagemap_evict_to_ram()および__drm_pagemap_migrate_to_ram()の両方からこれを使用するようにしました。
If you want to get the best quality for vulnerability data then you always have to consider VulDB.