Linux/Unix 主機上安裝了一個或多個受到弱點影響的套件，且廠商未提供可用的修補程式。

  - USB核心透過新增記憶體障礙修正 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 0 會看到舊的未遞減 urb->use_count 值而 CPU 1 會看到舊的未遞增 urb->reject 值。因此 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 Plugin ID 260501

版本 1.17