Linux/Unix 主机中安装的一个或多个程序包受到一个漏洞影响，而供应商没有提供补丁程序。

  - sched/fair：初始化 fork 实体时清除rel_deadline 当新 fork 的sched_entity进入 fair 类并意外设置了 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. 但是，fork 实体的期限不是此新计划实例的有效继承相对期限，因此转换会产生异常大的期限。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才有意义。新 fork 的 sched_entity 不应继承或保留此状态。清除 __sched_fork（） 中的 se->rel_deadline，以及其他sched_entity运行时状态，以便第一个排队时不会将新实体的期限解释为过时的相对期限。
    (CVE-2026-52980)

请注意，Nessus 依赖供应商报告的程序包是否存在进行判断。

检测

Linux Distros 未修补的漏洞：CVE-2026-52980

medium Nessus 插件 ID 323289

版本 1.1