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

  - USBcoreメモリバリアを追加することで usb_kill_urb のハングを修正します syzbot fuzzer は、usb_kill_urb() が返されるのを待機する際にプロセスがハングするバグを特定しました。問題はURBのリンク解除ではないことがわかりました。は問題なく動作します。問題は、URB が完了したというウェイクアップ通知を受信しない場合に発生します。理由は、SMP システムでのメモリアクセス順序です。アウトライン形式で、異なる CPU で同時に実行される usb_kill_urb() および __usb_hcd_giveback_urb() は、次のアクションを実行します。 CPU 0 CPU 1 ------------------------------------------------------ --- --------------------------------- usb_kill_urb()
    __usb_hcd_giveback_urb()... atomic_inc(&urb->reject); atomic_dec(&urb->use_count); ... ...
    wait_event(usb_kill_urb_queue, atomic_read(&urb->use_count) == 0); if (atomic_read(&urb->reject)) wake_up(&usb_kill_urb_queue);注意を urb->reject と urb->use_count に限定すると、CPU 0 でのアクセスの全体的なパターンは次のようになります。urb->reject に書き込み、urb->use_count を読み取ります。 CPU 1 でのアクセスの全体的なパターンは次のようになります。urb->use_count を書き込み、続いて urb->reject を読み取ります。このパターンは、メモリモデル業界では SB (ストアバッファリングの意味) と呼ばれています。また、メモリバリアの形式において -- 希望するアクセス順序の適切な強制なしで、書き込みの前に読み取りを実行するために、両方の CPU が書き込みを実行する可能性があります。その結果、CPU 1がurb->rejectの古い増加されていない値を確認するとき、CPU 0がurb->use_countの古い増加されていない値を確認することがあります。その結果、CPU 0 は待機キューに残り、決してウェイクアップされないため、usb_kill_urb() に確認されたハングアップが発生します。usb_poison_urb() および usb_hcd_submit_urb() の失敗パスウェイで、同じパターンのアクセスが発生します。この問題は、適切なメモリバリアを追加することで修正されます。
    SB パターンで適切なメモリアクセス順序を提供するには、両方の CPU でフルバリアが必要です。atomic_inc() および atomic_dec() アクセス自体は、メモリ順序を提供しませんが、これらが存在するため、さまざまなルーチンで最適化された smp_mb__after_atomic() メモリバリアを使用して、希望の効果を得ることができます。このパッチは、必要なメモリバリアを追加します。 (CVE-2022-48760)

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

検出

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

high Nessus プラグイン ID 260501

バージョン 1.17