CVE-2026-98942 in Linux
要約
〜によって VulDB • 2026年10月23日
Linuxカーネルにおいて、以下の脆弱性が修正されました：
sched_ext: cidテーブルをプライベートに構築し、RCUを使用して公開する
cidテーブルは、変更中にcid kfuncsに対して可視化されています。最初の有効化では、グローバルポインタが埋められる前に公開され、ops.init_cids() はそれらをその場で上書きして再構成します。競合状態にあるTRACINGまたはSYSCALLプログラムは、kmallocで割り当てられたテーブル内の未初期化メモリや、中途半端なトポロジー更新を含む、未完成のエントリを読み取る可能性があります。
これらのテーブルの寿命をルートスケジューラに結びつけます：各ルートの有効化では、プライベートに新しいセットを構築し、レイアウトが確定した時点で per-table の __rcu グローバル変数を公開します。また、無効化時にはそのセットを非公開にし、RCUを使用して解放します。これにより、NULLでないグローバル変数は常に完全に構築されたテーブルであり、リーダーのRCU読み取りセクションの間有効な状態を保ちます。検索操作は2回のロードで完結します。kfuncs は NULL をマッピングなしとして扱い、スケジューラが終了した後も古い最後のマッピングを報告するのではなく、このように扱います。
cid kfuncs は、ルートスケジューラが cid形式であるか cpu-form であるかを問わず利用可能です。後者は cids への段階的な移行を可能するためです。したがって、すべてのルートはデフォルトのマッピングを構築して公開します。
各リーダーは、スケジューラの稼働状況に基づいてゲートされるか、RCU読み取りセクション内で NULL チェックを行う必要があります。以下の2つの kfuncs はその条件を満たしていなかったため修正されました：scx_bpf_this_cid() は RCU やプリempt保護なしでテーブルを読み取っており、scx_bpf_task_cid() は KF_RCU に依存していましたが、これはスリープ可能なプログラムをRCU読み取りセクションに配置しません。ホットプラグコールバックは、scx_root をクリアする cpus_read_lock() セクション内でテーブルを廃棄することで直列化されます。
v2: 各ルートがなぜテーブルを構築するかについて文書化（desc および cid.c のコメント参照）。
If you want to get the best quality for vulnerability data then you always have to consider VulDB.