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

  - sched/fair：初始化分叉實體時清除rel_deadline 當新分叉的sched_entity意外設定 se->rel_deadline 進入公平類別時，可能會發生 yield 觸發的當機。失敗的順序為：1.當 se->rel_deadline 仍處於設定狀態時，任務被分叉。2、__sched_fork（）初始化vruntime、vlag等sched_entity狀態，但不清除rel_deadline。3. 在第一次排隊時，enqueue_entity（） 呼叫 place_entity（）。4、因為設定了se->rel_deadline，所以place_entity（）將se->deadline視為相對截止時間，透過新增目前vruntime將其轉換為絕對截止時間。5. 但是，分叉實體的截止日期並不是此新調度實例的有效繼承相對截止日期，因此轉換會產生異常大的截止日期。6. 如果任務稍後呼叫 sched_yield（），yield_task_fair（） 會將 se->vruntime 推進至 se->deadline。7. 然後，膨脹的 vruntime 會由下列佇列路徑使用，其中 vruntime 衍生的金鑰乘以實體權重時可能會溢位。8. 這會破壞cfs_rq>sum_w_vruntime，破壞 EEVDF 資格計算，並最終使所有實體看起來不合格。然後，pick_next_entity（） 可能會意外傳回 NULL，導致稍後的 NULL 解除參照。捕獲的痕跡清楚地顯示了效果。在 yield 之前，實體的 vruntime 大約是： 9834017729983308 執行 yield_task_fair（） 後： se->vruntime = se->deadline vruntime 跳到： 19668035460670230，截止日期後來進一步推進到： 19668035463470230 這表明在 yield_task_fair（） 將其複製到 vruntime 之前，截止日期已經變得異常大。只有當 se->deadline 確實帶有仍然需要針對 vruntime 放置的相對截止日期時，rel_deadline才有意義。新分支的sched_entity不應繼承或保留此狀態。清除 __sched_fork（） 中的 se->rel_deadline，以及另一個sched_entity執行階段狀態，這樣第一個佇列就不會將新實體的截止日期解譯為過時的相對截止日期。
    (CVE-2026-52980)

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

偵測

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

medium Nessus Plugin ID 323289

版本 1.4

版本 1.3

版本 1.2

版本 1.1

版本 1.4 Jul 10, 2026, 4:01 PM Detection (updated detection logic) Plugin metadata Plugin Feed: 202607101601
版本 1.3 Jul 2, 2026, 3:38 PM Detection (updated detection logic) Plugin Feed: 202607021538
版本 1.2 Jun 30, 2026, 11:58 AM Detection (updated detection logic) Plugin metadata Plugin Feed: 202606301158
版本 1.1 Jun 28, 2026, 7:50 AM New Plugin Feed: 202606280750