CVE-2026-52980

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> sched/fair: Clear rel_deadline when initializing forked entities<br /> <br /> A yield-triggered crash can happen when a newly forked sched_entity<br /> enters the fair class with se-&gt;rel_deadline unexpectedly set.<br /> <br /> The failing sequence is:<br /> <br /> 1. A task is forked while se-&gt;rel_deadline is still set.<br /> 2. __sched_fork() initializes vruntime, vlag and other sched_entity<br /> state, but does not clear rel_deadline.<br /> 3. On the first enqueue, enqueue_entity() calls place_entity().<br /> 4. Because se-&gt;rel_deadline is set, place_entity() treats se-&gt;deadline<br /> as a relative deadline and converts it to an absolute deadline by<br /> adding the current vruntime.<br /> 5. However, the forked entity&amp;#39;s deadline is not a valid inherited<br /> relative deadline for this new scheduling instance, so the conversion<br /> produces an abnormally large deadline.<br /> 6. If the task later calls sched_yield(), yield_task_fair() advances<br /> se-&gt;vruntime to se-&gt;deadline.<br /> 7. The inflated vruntime is then used by the following enqueue path,<br /> where the vruntime-derived key can overflow when multiplied by the<br /> entity weight.<br /> 8. This corrupts cfs_rq-&gt;sum_w_vruntime, breaks EEVDF eligibility<br /> calculation, and can eventually make all entities appear ineligible.<br /> pick_next_entity() may then return NULL unexpectedly, leading to a<br /> later NULL dereference.<br /> <br /> A captured trace shows the effect clearly. Before yield, the entity&amp;#39;s<br /> vruntime was around:<br /> <br /> 9834017729983308<br /> <br /> After yield_task_fair() executed:<br /> <br /> se-&gt;vruntime = se-&gt;deadline<br /> <br /> the vruntime jumped to:<br /> <br /> 19668035460670230<br /> <br /> and the deadline was later advanced further to:<br /> <br /> 19668035463470230<br /> <br /> This shows that the deadline had already become abnormally large before<br /> yield_task_fair() copied it into vruntime.<br /> <br /> rel_deadline is only meaningful when se-&gt;deadline really carries a<br /> relative deadline that still needs to be placed against vruntime. A<br /> freshly forked sched_entity should not inherit or retain this state.<br /> Clear se-&gt;rel_deadline in __sched_fork(), together with the other<br /> sched_entity runtime state, so that the first enqueue does not interpret<br /> the new entity&amp;#39;s deadline as a stale relative deadline.