CVE-2026-89540 in Linux
要約
〜によって VulDB • 2026年09月12日
Linuxカーネルにおいて、以下の脆弱性が修正されました：
sunrpc: /proc エントリを公開する前に gssp_lock を初期化する
create_use_gss_proxy_proc_entry() 関数は、init_gssp_clnt() が sn->gssp_lock に対して mutex_init() を実行する前に、proc_create_data() を介して /proc/net/rpc/use-gss-proxy のエントリを公開します。dentry が proc_subdir_lock でリンクされると、ユーザーランドから即座に到達可能になるため、このタイミングで書き込みが行われると set_gssp_clnt() 内でゼロ初期化された struct mutex に対して mutex_lock() が実行されます。
create_use_gss_proxy_proc_entry(net) proc_create_data("use-gss-proxy", ...) /* dentry は生存中 */ init_gssp_clnt(sn) mutex_init(&sn->gssp_lock) /* 遅すぎる */
write_gssp() set_gssp_clnt(net) mutex_lock(&sn->gssp_lock) /* 未初期化 */ gssp_rpc_create(...) sn->gssp_clnt = clnt mutex_unlock(&sn->gssp_lock)
この競合状態のウィンドウは、proc_create_data() の戻り値と init_gssp_clnt() の実行という2つのステートメントの間のみです。したがって、登録スレッドがここでプリエンプション（割り込み）され、かつ別のタスクが新しく公開されたファイルを開いている場合に限り、書き込み側がこのウィンドウに到達します。register_pernet_subsys() は pernet_ops_rwsem 下でプリエンプティブなコンテキストで実行されるため、このプリエンプションは可能です。また、auth_rpcgss モジュールのロード時には proc エントリが既に実行中のタスクを持つすべての生きている net namespace に対して作成されるため、ウィンドウは拡大します。
競合に勝った書き込み側はゼロ埋めされた struct mutex をロックしようとします。CONFIG_DEBUG_MUTEXES が有効な場合、欠落したマジック値により「lock used without init」の splat（エラー出力）が発生しますが、本番用カーネルでは fast path 経由で CMPXCHG(owner, 0, current) によってロックが取得されます。後者のケースでは、init_gssp_clnt() が owner を再ゼロ化する前に到着した2番目の書き込み側は set_gssp_clnt() に同時に進入し、使用中の最初の書き込み側の clnt をシャットダウンして、敗者（loser）の clnt リークを引き起こします。
修正方法：sn->gssp_lock の初期化を sunrpc_init_net() 内で行い、そのライフタイムが sn->gssp_clnt が存在する sunrpc_net と一致するようにします。sn->gssp_clnt は net_generic ストレージを支える kzalloc から既に NULL ですのて、遅延ヘルパーは不要になりました。init_gssp_clnt()、そのプロトタイプ宣言、および create_use_gss_proxy_proc_entry() からの呼び出しを削除します。sunrpc.ko は auth_rpcgss.ko のビルド時の依存関係であるため、sunrpc_init_net() はどの auth_gss pernet init が proc エントリを公開する前にも常にすべての netns で実行されてきました。
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.