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

  - sched/rt：對於非 PREEMPT_RT RT 移轉會積極完成，RT_PUSH_IPI必須預設為關閉。當 CPU 為較低優先順序的工作排程高優先順序的 RT 工作時，它會查看是否有任何 RT 工作正在等待在另一個優先順序高於此 CPU 即將執行的工作的 CPU 上執行。如果找到一個，它會將該任務拉到 CPU 並允許它在那裡運行。通常，此提取是透過查看 RT 超載遮罩 （rto） 來完成的，其中包含排程器網域中具有 RT 任務的所有 CPU，這些 RT 任務由於目前在其 CPU 上執行較高優先順序的 RT 任務而等待執行。即將排程優先順序較低任務的 CPU 將抓取超載 CPU 的 rq 鎖，並將 RT 任務從該 CPU 的執行佇列移至本機佇列，並排程優先順序較高的 RT 任務。當許多 CPU 同時排程優先順序較低的任務時，這會導致問題。他們都會嘗試獲取具有超載 RT 任務的 CPU 的相同運行隊列鎖。只有第一個進入的 CPU 才能獲得該任務。所有其他人都會等到他們獲得執行佇列鎖定，然後看到沒有什麼可拉的，什麼都不做。在具有大量 CPU 的系統上，這會導致大延遲（高達 500us），這超出了PREEMPT_RT允許的範圍。解決這個問題的方法是創建一個RT_PUSH_IPI邏輯。當任何 CPU 想要拉取任務時，它不會獲取超載 CPU 的 runqueue 鎖，而是首先向超載的 CPU 發送 IPI，並且該 IPI 處理常式會讓具有等待 RT 任務的 CPU 進行推送。然後，該處理常式會將 IPI 傳送到下一個具有超載 RT 任務的 CPU，依此類推。請注意，在第一個 CPU 啟動此處理程序之後，如果另一個 CPU 想要執行拉取，它會看到該處理程序已開始，並且只會遞增計數器以使 IPI 再次繼續。此RT_PUSH_IPI解決了 PREEMPT_RT 的延遲問題，但可能會導致非PREEMPT_RT的新問題。也就是說，softirq 在PREEMPT_RT上的執行緒內容中執行，但它們可以在非 RT 的中斷內容中執行。如果 IPI 落在剛剛喚醒多個 RT 任務的 CPU 上，而當前 CPU 正在執行非 RT 或低優先順序的 RT 任務，則它不會進行推送，而只是在該 CPU 上執行排程。但是，如果 softirq 也在此 CPU 上執行，則排程需要等到 softirq 完成。在那之前，CPU 仍會被視為過載，因為仍有 RT 工作等待在其上執行。在大型機器上執行大量網路流量的工作負載上發生即時鎖定，其中 softirq 將執行 500us 中的 750us。它也會喚醒 RT 任務，導致 RT 拉取邏輯不斷執行。當 RT 任務已排入佇列但尚未執行的 CPU 上觸發 softirq 時，其他 CPU 會認為此 CPU 過載，他們會向其發送 IPI。CPU 會注意到等待的 RT 任務的優先順序高於目前執行的任務，只需排程該 CPU。但由於 softirq 正在執行，因此在排程之前，它會收到另一個 IPI 來執行相同的動作。IPI 的數量會大大減慢當前運行的 softirq 的速度，以至於在它返回任務上下文之前，它會執行另一個 softirq，永遠不會允許 CPU 排程。這即時鎖定了該 CPU。由於建立RT_PUSH_IPI是為了協助PREEMPT_RT，因此如果未啟用PREEMPT_RT則將其設為預設關閉。（CVE-2026-64374）

請注意，Nessus 的判定取決於廠商所報告的套件是否存在。

偵測

Linux Distros 未修補弱點：CVE-2026-64374

high Nessus Plugin ID 329952

版本 1.32