Linux/Unix ホストには、ベンダーが提供するパッチが利用できない脆弱性の影響を受ける複数のパッケージがインストールされています。

  - bpfARG_CONST_ALLOC_SIZE_OR_ZERO に対して mark_chain_precision を行います。高精度マーカーは、ARG_CONST_* スタイル引数がある場合は常に伝播する必要があります。これは、このような引数が戻り値を微調整するとき、検証子は state_equal チェックの目的で不正確なスカラーを同等と見なさないためですこの場合PTR_TO_MEM に mem_size を設定してください。R0に対する結果のmem_sizeは定数値から派生しており、検証機能がそのような引数が存在するときに等価であると考えて状態を誤ってプルーニングした場合、regsafeでは両方のレジスターがfalseであることを確認することで、無効な状態で終了する可能性があります。探索された状態で正しい mem_size となるべきものを超えてアクセスできる検証子を渡すプログラム。問題の具体的な例を示すと <prog>次のようになります 0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000 = 4 4if r3 > r2 goto +18 <LBB5_5> 5w2 = 0 6*(u32
    *)(r1 + 0) = r2 7: r1 = *(u32 *)(r1 + 0) 8: r2 = 1 9: w1 == 0 goto +1 の場合 <LBB5_3> 10: r2 = -1 0000000000000058 <LBB5_3>11r1 = 0 ll 13 r3 = 0 14 bpf_ringbuf_reserve を呼び出します 15 r0 == 0 goto +7 の場合 <LBB5_5> 16 r1 = r0 17r1 += 16777215 18 w2 = 0 19 *(u8 *) (r1 + 0) = r2 20r1 = r0 21r2 = 0 22
    bpf_ringbuf_submit 0000000000000b8 <LBB5_5>23: w0 = 0 24: exit UINT_MAX) を操作する際に、insn 9 での w1 は常に 0 になるため、runtime では bpf_ringbuf_reserve から UINT_MAX/4 を超えるエラーは発生しません。regsafe 中の検証機能は、両方の状態の両方の r2 レジスタに対して、reg->precise を「false」と見なします。このため、states_equal のためにはそれらを等しいと見なします。バックトラッキングサポートを使用して正確なマーカーを伝播した場合、正確なマーキングを使用して、古い r2UINT_MAXが新しい r2 内にあることを保証することになりますが、これは決して真ではないため、検証は正しく失敗します。結果として、命令19の領域外アクセスがこの修正なしで許可されることになります。ユーザーが CAP_BPF を持たない場合または subprog カウントが 1 より大きい場合つまり静的関数やグローバル関数を使用する場合、reg->precise は常に true に設定されるため、これは精度マークが必要な場合にのみ問題となることに、注意してください。明示的に伝播される (すなわち CAP_BPF を持つ特権ユーザー)。将来の回帰を防ぐために、簡素化されたテストケースが次のパッチに含まれています。
    (CVE-2022-49961)

Nessus は、ベンダーによって報告されたパッケージの存在に依存していることに注意してください。

検出

Linux Distros のパッチ未適用の脆弱性: CVE-2022-49961

high Nessus プラグイン ID 245820

バージョン 1.22