CVE-2022-50650 in Linux
要約
〜によって VulDB • 2026年06月28日
Linuxカーネルにおいて、以下の脆弱性が修正されました：
bpf: 同期コールバックの参照状態管理を修正
現在、検証器（verifier）はコールバック関数（同期および非同期）が1回だけ実行されると仮定して検証を行います。つまり、関数が一度呼び出されたかのように実行状態を検索します。次に検索する命令はサブプロシージャの先頭に設定され、ネストしたフレームからの脱出は `curframe > 0` および `prepare_func_exit` を使用して処理されます。非同期コールバックの場合、カスタムスタックプッシュのカスタマイズされたバリアントを使用して、非同期コールバック用のカスタム状態と実行コンテキストを設定するための分岐をシミュレートします。
このアプローチは単純であり、コールバックが実際に1回だけ実行される場合には機能しますが、現在存在する `for_each` 形式のヘルパー関数（つまり、コールバックを複数回実行するもの）にとっては安全ではありません。
呼び出し元の取得した参照を解放するコールバックは、それを複数回行う可能性があります。しかし、現在の検証器ではこれをフレーム内の1回の呼び出しとして認識し、その後呼び出し元に返却します。そのため、検証器は、例えば `callback_ctx`（スタック上のスパイルドされた型付きレジスタからcb内で埋められるレジスタ）を通じてコールバックがアクセスした参照を解放したと誤認します。
同様に、コールバック内部で取得呼び出しがペアになっていないことを検出する可能性があります。その場合、呼び出し元はコールバックの参照状態をコピーし、新しい `ref_obj_ids` を持つレジスタを解放する必要があります。しかし再び、コールバックは複数回実行される可能性がありますが、検証器はそのようなケースでも単一のシンボリック実行における取得済み参照のみを対象とするため、リークが発生します。
非同期コールバックの場合については事情が異なります。現在、`bpf_timer_set_callback` はこれを1回だけ実行しますが、仮に複数回実行されたとしても安全です。なぜなら、参照状態はNULLであり、`check_reference_leak` が `BPF_EXIT` 前にプログラムに対して状態を解放させるためです。また、この状態は呼び出し元フレームの解析の影響を受けません。したがって、非同期コールバックは安全です。
私たちは参照状態にアクセス可能である必要があり（例えば、`callback_ctx` の `PTR_TO_STACK` を通じてスタックから読み込まれたポインタなど）、そのため依然として呼び出し元の `reference_state` をコールバックの `bpf_func_state` にコピーする必要がありますが、その参照状態に追加されるあらゆる参照は `BPF_EXIT` 前に解放されていることを強制します。これには、呼び出し元と被呼び出し側の参照を区別するために、参照状態内に新しい `callback_ref` メンバーを導入することが必要です。したがって、`check_reference_leak` は現在、コールバック関数の中にあり、かつ `callback_ref` 参照が解放されていない場合にエラーとなります。フレーム0 -> cb1 -> cb2 などのように複数のネストされたコールバックが存在し得るため、この特定の参照がこのコールバックフレームに属するのか親フレームに属するのかを区別する必要があり、自分自身のものに対してのみエラーとする必要があります。そのため、状態 `state->frameno`（コールバックでは常に0以外）を保存します。
要約すると、コールバックは呼び出し元の `reference_state` を読み取ることができますが、それを改変することはできません（これにより、呼び出し元によって取得されたポインタを使用できます）。彼らは返却する前に（つまり、呼び出し元とコールバックの状態が一致するため、それを呼び出し元にコピーし直す必要がない時点で）、呼び出し元の参照状態の上に自分自身の変更を巻き戻す必要があります（`BPF_EXIT` 前に自身の `acquired_refs` を解放することによって）。
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.