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

  - sched/rt，dl：挑選推送候選項目時，跳過已停用移轉的工作 migrate_disable（） 的 RT 工作無法移動至另一個 CPU，但排程器仍會將此類工作保留在該 CPU 的可推送清單 （rq->rt.pushable_tasks） 上，且仍將執行佇列標記為 RT 超載 （rq->rt.overloaded = 1）。所以 RT 平衡器一直把這個 CPU 當作有一個任務要移開，並不斷嘗試移動任務，但推送永遠無法成功。當頭部被固定時，push_rt_task（） 也不會放棄。它會回退到推送 rq->curr，而是使用 per-CPU 終止符，如提交 a7c81556ec4d 所新增的那樣（sched：修正 migrate_disable（） 與 rt/dl 平衡）。CPU 在此重試迴圈中花費數十毫秒。核心被隔離以進行即時工作，但在迴圈期間，其近一半的時間被無法成功的推送所消耗。受影響 CPU 的 ftrace 擷取，啟用 sched_switch 並套用提交 94894c9c477e （sched/rt： 跳過 rto_next_cpu（） 中目前執行的 CPU），顯示 CPU 時間的去向。兩個優先順序相等的SCHED_FIFO任務共用 CPU，taskA migrate_disable（）並排入佇列，taskB 作為 rq->curr。在一個 89 毫秒的視窗中，taskB 只有 52 毫秒的 CPU。其他 37 毫秒用於塞子線程。
    調度器不斷嘗試推送 taskA（可推送清單的固定頭），轉而推送 taskB，並喚醒塞子 5204 次。每一次推送都失敗了，也沒有移動任何任務。taskA 保持可執行狀態，並一直排入佇列，從未執行。推送 taskB 在重新檢查時失敗。
    find_lock_lowest_rq（） 會捨棄 rq 鎖定以取得目標 rq 鎖定，然後使用任務 ！= pick_next_pushable_task（rq） 再次檢查。推送的任務是 taskB，但 pick 會傳回 taskA，即可推送清單的頭部。taskB 是 rq->curr，而 set_next_task_rt（） 會從該清單中移除正在執行的任務，因此 taskB 永遠不可能成為頭部。檢查預期從可推送清單中取得候選項目，但後援會推送 rq->curr，而該清單中永遠不會出現。所以每次檢查都失敗。.--> push-IPI 到達 | | |v |pushable head = taskA -> 固定，無法推送 | | |v |所以推送 taskB 而不是 -> wake migration/N，一個 stop-class | |執行緒，因此它會搶佔 taskB |v |重新檢查將 taskB 與可推桿頭進行比較， |這還是taskA ->放棄 | | |v |未移動任何內容，taskA 仍排入佇列，rq 仍超載 | |「----------」每 ~17 次重複一次，5204 次，持續 89 毫秒循環無法自行停止。每一輪都會完全保持原樣離開執行佇列，因此下一個推送 IPI 會執行相同的操作。在捕獲中，只有當任務 B 自行進入睡眠狀態時，它才結束。然後在本地選擇 taskA 並離開可推送清單。視窗中每個任務的 CPU 時間，從 sched_switch開始：taskB 51.95 ms 實際工作遷移/N 37.18 ms 無移動 taskA 0.00 ms 全程排隊，從未挑選空閒 0.01 ms 在同一視窗中計數：此 CPU 上處理了 7667 個 push-IPI 17481 pick_next_pushable_task（） 傳回 taskA，仍固定 5204 find_lock_lowest_rq（） 放棄重新檢查 1 個推送，實際完成了 0 次任務 A 的遷移 CPU 時間和視窗長度來自標準sched_switch追蹤點。此調查需要在 RT 平衡器內新增計數追蹤點。自我 IPI 路徑被上面的 rto_next_cpu（） 修復關閉，該部分有效。但執行佇列仍會標示為過載，因為釘選工作仍會公告為可推送。其他 CPU 現在會在自己的 RT 平衡期間傳送 push-IPI，並且相同的迴圈會再次執行。關閉自我 IPI 路徑並未停止 pinn ---truncated--- （CVE-2026-98087）

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

偵測

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

medium Nessus Plugin ID 350667

版本 1.3