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

  - 已解決 Linux 核心中的下列弱點：idpf：將工作佇列轉換為取消繫結。當使用「WQ_UNBOUND」建立工作佇列時，其工作項目會由特殊的背景工作集區提供，而其主機背景工作並未繫結至任何特定 CPU 。在預設設定中 (即當「queue_delayed_work」和好友未指定在哪個 CPU 上執行工作項目時)，「WQ_UNBOUND」允許在將工作項目排入佇列的 CPU 的相同節點中的任何 CPU 上執行工作項目。此解決方案可能會放棄局部性，但它可以避免與可能主控工作項目所在處理器的 CPU 時間的其他處理程序發生爭用情形。這不只是理論上的問題：在特定情況下，錯誤設定的處理程序會獨占 CPU0 的大部分時間，將不到 0.5% 的 CPU 時間留給 kworker。在 CPU0 上使用 kworker 的 IDPF 工作佇列因此出現大量完成延遲，進而造成效能降低、逾時及最終系統當機。* 我也執行了手動測試，以評估效能改善狀況。測試包含盡可能多消耗 CPU 0 的對抗處理程序 (「./stress --cpu 2」)。此處理程序會在「taskset 01」下執行，以將其繫結至 CPU0。啟動後，其優先順序會變更為「chrt -pQ 9900 10000 ${pid}」和「renice -n -20 ${pid}」。然後，系統會強制 IDPF 驅動程式偏好 CPU0，方法是將所有「queue_delayed_work」、「mod_delayed_work」等呼叫... 改為使用 CPU 0。最後，收集工作佇列事件的「ktraces」。如果沒有最新的修補程式，對抗處理程序可強制在「workqueue_queue_work」和「workqueue_execute_start」之間發生任意延遲。在我的測試中，此延遲高達「30ms」。套用最新的修補程式後，工作佇列可移轉至相同節點中另一個未載入的 CPU，且在其他條件保持不變的情況下，我所看到的最大延遲為「6us」。(CVE-2024-58057)

請注意，Nessus 依賴供應商報告的套件存在。

偵測

Linux Distros 未修補弱點：CVE-2024-58057

medium Nessus Plugin ID 232275

版本 1.19