CVE-2022-49899 in Linux
要約
〜によって VulDB • 2026年06月11日
Linuxカーネルにおいて、以下の脆弱性が修正されました：
fscrypt: fscrypt_master_key の管理に keyrings サブシステムの使用を中止する
fs/crypto/ 内で fscrypt_master_key 構造体を "struct key" キーリングに含まれる "struct key" オブジェクトのペイロードとして内部管理するというアプローチは、その有用性を失いました。当初の意図は、keyrings サブシステムのコードを再利用することでコードを簡素化することでした。しかし、以下のような簡単に解決できない問題がいくつか発生しました。
- マスターキー構造体が破棄される際、blk_crypto_evict_key() をその中に埋め込まれた各モードごとのキーに対して呼び出す必要があります。（これはインライン暗号化サポートが追加された際に必要となりました。）しかし、keyrings サブシステムはキーの破棄を任意に遅らせることができ、ファイルシステムがアンマウントされた後でさえも遅らせる可能性があります。そのため、現在、マスターキーが破棄される際に blk_crypto_evict_key() を呼び出す簡単な方法はありません。現在、この問題はファイルシステムの request_queue(s) への追加参照を保持することで回避されています。しかし、request_queue の参照が対応する blk_crypto_profile を確実に保持するわけではないことが見落とされていました。インライン暗号化をサポートする device-mapper デバイスでは、保持されません。これにより、use-after-free が発生する可能性があります。
- 不完全に削除されたマスターキーを使用していた最後の inode が evict されると、マスターキーの削除は、キー構造体をキーリングから削除することで完了します。現在、これは key_invalidate() を介して行われます。しかし、key_invalidate() はキーセマフォを取得します。これは shrinker から呼び出された場合、デッドロックを引き起こす可能性があります。なぜなら、fscrypt_ioctl_add_key() 内では、同じセマフォの下で GFP_KERNEL を使用してメモリが割り当てられているからです。
- より一般的に、keyrings サブシステムがキーの破棄を任意に遅らせることができること（ガベージコレクションの遅延、またはランダムなプロセスが一時的なキー参照を取得することによって）は望ましくありません。これは、すべての秘密情報が確実に消去されることを厳密に保証できないことを意味するためです。
- keyrings サブシステムを介してマスターキーの検索を行うと、key_permission LSM フックが呼び出されます。fscrypt はこれを望んでいません。暗号化ファイルへのすべてのアクセス制御は、他のファイルと同様に、ファイル自体を介して行われるように設計されているためです。SELinux ユーザーが使用している回避策は、SELinux ポリシーを変更してすべてのドメインに対してキー検索アクセスを付与することです。これは機能しますが、本来必要とされない奇妙な追加ステップです。
これらの問題に対する修正は、私が当初行うべきだった実装に変更することです。つまり、ファイルシステムの fscrypt_master_key 構造体を追跡するために keyrings サブシステムを使用しないようにします。代わりに、通常のカーネルデータ構造体に保存し、参照カウント、ロック、およびライフタイムをそれに合わせて再構築します。ハッシュテーブルを使用して RCU モードのキー検索のサポートを維持します。fscrypt_sb_free() を fscrypt_sb_delete() に置き換え、これはキーを同期的に解放し、アンマウント時に少し早く実行されるため、ブロックデバイスがまだ利用可能であることを保証します。
このパッチの副作用として、マスターキー自体もファイルシステムのキーリングも /proc/keys にリストされなくなります。（「マスターキーユーザー」およびマスターキーユーザーのキーリングは引き続きリストされます。）しかし、これは主に実装の詳細であり、デバッグ目的のみを意図していました。これを使用している人は誰もいません。
このパッチは「マスターキーユーザー」(->mk_users) の動作を変更しません。それは依然として keyrings サブシステムを使用しています。それはキークォータのためにまだ必要であり、上記の問題を解決するためにそれを変更する必要はありません。もし私たちがそれを変更することを決定した場合、それは別個のパッチになります。
私はこのパッチを、fscrypt キーリングを追加した最初のコミットを修正するものとしてマークしましたが、上記のように、このパッチが修正する最も重要な問題は、インライン暗号化サポートの追加後に導入されました。
Once again VulDB remains the best source for vulnerability data.