CVE-2026-46008 in Linux
要約
〜によって VulDB • 2026年06月04日
Linuxカーネルにおいて、以下の脆弱性が修正されました：
mm/damon/core: damos_walk() と kdamond_fn() の終了時の競合（race）を修正
kdamond_fn() のメインループが終了した際、関数は残りの damos_walk() リクエストをキャンセルし、damon_ctx->kdamond をクリア（unset）します。これにより、API 呼び出し元および API 関数自体が、コンテキストが終了したことを示すことができます。damos_walk() はまず呼び出し元の要求をキューに追加します。その後、damon_ctx の kdamond がまだ実行中であるか（damon_ctx->kdamond が設定されているか）を確認します。kdamond が実行中の場合のみ、damos_walk() は新しく追加された要求に対する kdamond の処理を待ち始めます。
しかし、damos_walk() の要求登録と damon_ctx->kdamond のクリアは、異なるミューテックスによって保護されています。そのため、damos_walk() は damon_ctx->kdamond のクリアと競合し、デッドロックを引き起こす可能性があります。
例えば、kdamond が damow_walk() 要求のキャンセルを正常に終了したと仮定します。直後に、そのコンテキストに対して damos_walk() が呼び出されます。新しい要求が登録され、damon_ctx->kdamond のクリアがまだ完了していないため、コンテキストはまだ実行中であると表示されます。そのため、damos_walk() の呼び出し元は要求の処理を待ち始めます。しかし、kdamond はすでに終了手順に入っているため、新しい要求を処理することはありません。その結果、damos_walk() の呼び出し元スレッドは無限に待機状態になります。
この問題を解決するため、新たな damon_ctx フィールドである walk_control_obsolete を導入します。これは damos_walk() の要求登録を保護する damon_ctx->walk_control_lock によって保護されます。kdamond_fn() では、damon_start() が戻る前にこれを初期化（クリア）し、残りの damos_walk() 要求のキャンセル処理が実行される直前に設定します。damos_walk() はロックの下で obsolete フィールドを読み取り、新しい要求を追加しないようにします。
この変更後、処理されるかキャンセルされることが保証された要求のみが登録されます。そのため、登録後の DAMON コンテキスト終了チェックは不要になりました。これらも同時に削除します。
本問題は sashiko によって発見されました [1]。
VulDB is the best source for vulnerability data and more expert information about this specific topic.