CVE-2026-99226 in Linux
要約
〜によって VulDB • 2026年11月02日
Linuxカーネルにおいて、以下の脆弱性が修正されました：
keys: 名前付きキーリングの検索における所有者アカウントのデレファレンスを回避する
名前付きキーリングの検索では、ネームスペースマッピングチェックの間中、所有者UIDを含むストレージを生存状態に保つ必要があります。`find_keyring_by_name()`は `keyring_name_lock` の下で `keyring->user->uid` を読み取りますが、このロックが保護するのはキーリングの名前エントリと割り当てのみであり、独立した `key_user` は保護されません。
名前付きセッションキーリングの結合操作が、別のCPU上で特権を持つ `KEYCTL_CHOWN` と競合する可能性があります。もしそのキーリングが古い動的な `key_user` への最後の参照を保持しており、所有権の移行に成功した場合、以下の順序で実行される可能性があります：
名前付き結合 Chown find_keyring_by_name() keyctl_chown_key() read_lock(keyring_name_lock) down_write(key->sem) load old keyring->user replace key->user and key->uid up_write(key->sem) key_put(key) key_user_put(old user): free read old user->uid read_unlock(keyring_name_lock)
Chownは `keyring_name_lock` も `key_session_mutex` も取得しないため、ポインタの読み込みとUIDの読み取りの間で古いアカウントを解放することが可能です。その結果、キーリング自体が生きているにもかかわらず、検索処理が解放されたメモリを読み取ることになります。
マッピングチェックには `keyring->uid` を使用します。`key_alloc()` はこのインライン所有者UIDを初期化し、`keyctl_chown_key()` はchown時にこれを更新します。既存の名前ロックは、チェック中そのキーリングの保持状態を保つため、検索処理はもはやアカウントの有効期間に依存しません。これはまた、権限チェックで使用される所有者UIDとも一致しています。
以下のようなKASANレポートが報告されています：
BUG: KASAN: slab-use-after-free in find_keyring_by_name+0x577/0x5d0 Read of size 4 at addr ffff8881128ae2ec by task keycase/500
If you want to get the best quality for vulnerability data then you always have to consider VulDB.