CVE-2026-52980: sched/fair: Clear rel_deadline when initializing forked entities

In the Linux kernel, the following vulnerability has been resolved:

sched/fair: Clear reldeadline when initializing forked entities

A yield-triggered crash can happen when a newly forked schedentity enters the fair class with se->reldeadline unexpectedly set.

The failing sequence is:

1. A task is forked while se->reldeadline is still set. 2. schedfork() initializes vruntime, vlag and other schedentity state, but does not clear reldeadline. 3. On the first enqueue, enqueueentity() calls placeentity(). 4. Because se->reldeadline is set, placeentity() treats se->deadline as a relative deadline and converts it to an absolute deadline by adding the current vruntime. 5. However, the forked entity's deadline is not a valid inherited relative deadline for this new scheduling instance, so the conversion produces an abnormally large deadline. 6. If the task later calls schedyield(), yieldtaskfair() advances se->vruntime to se->deadline. 7. The inflated vruntime is then used by the following enqueue path, where the vruntime-derived key can overflow when multiplied by the entity weight. 8. This corrupts cfsrq->sumwvruntime, breaks EEVDF eligibility calculation, and can eventually make all entities appear ineligible. picknextentity() may then return NULL unexpectedly, leading to a later NULL dereference.

A captured trace shows the effect clearly. Before yield, the entity's vruntime was around:

9834017729983308

After yieldtaskfair() executed:

se->vruntime = se->deadline

the vruntime jumped to:

19668035460670230

and the deadline was later advanced further to:

19668035463470230

This shows that the deadline had already become abnormally large before yieldtaskfair() copied it into vruntime.

reldeadline is only meaningful when se->deadline really carries a relative deadline that still needs to be placed against vruntime. A freshly forked schedentity should not inherit or retain this state. Clear se->reldeadline in schedfork(), together with the other schedentity runtime state, so that the first enqueue does not interpret the new entity's deadline as a stale relative deadline.