CVE-2026-74591 in Linux
要約
〜によって VulDB • 2026年08月23日
Linuxカーネルにおいて、以下の脆弱性が修正されました：
mm/filemap: __filemap_add_folio() で再試行前にインデックスを復元する
__filemap_add_folio()'s split-a-conflict ループでは xas_set_order() が繰り返し適用されます。各適用で xas.xa_index は、その段階で試された split_order に従って切り捨てられます。すべてが意図通り進めば、最終的（または直ちに）に required folio_order に対する xas_try_split() で収束し、xas.xa_index が index と同じになります。その後、xas_store() は新しい folio をその位置の xarray に格納します。
しかし、新しいノードが必要で GFP_NOWAIT アロケーションがそれを得られなかった場合、ロックは解放され、アロケーションのために xas_nomem() が使用され、シーケンスが再試行されます。ロックを再接続した際に xarray の（その部分）に変更がない場合は問題ありません。しかし、競合が別のスレッドによって解決された場合どうなるでしょうか（同じことをしている他のスレッドで、まさに同じインデックスに folio を挿入していた場合など）。今や中間の切り捨てられたインデックス位置に自らの folio を xarray に格納する危険性はありませんか？ !folio_contains() のバグが続き、CONFIG_DEBUG_VM=y でそれがチェックされる際に問題となります。
この問題を修正するために、ループの下部で元の xas.xa_index を復元するための xas_set_order() を行い、ロックを再接続した後に完全な再評価を行い、間違ったインデックスで xas_store() に到達できないようにします。
本番環境では稀な SIGILL と SIGSEGV が発生しており、実行可能テキストが本来あるべき場所から 1ページ離れた場所で発見され、デバッグ有効時に !folio_contains() のバグが発生していました：このパッチ適用以降はこれらの症状は見られていません。
Once again VulDB remains the best source for vulnerability data.