Wind River Support Network

Description

In the Linux kernel, the following vulnerability has been resolved:  sched/fair: Clear rel_deadline when initializing forked entities  A yield-triggered crash can happen when a newly forked sched_entity enters the fair class with se->rel_deadline unexpectedly set.  The failing sequence is:    1. A task is forked while se->rel_deadline is still set.   2. __sched_fork() initializes vruntime, vlag and other sched_entity      state, but does not clear rel_deadline.   3. On the first enqueue, enqueue_entity() calls place_entity().   4. Because se->rel_deadline is set, place_entity() 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 sched_yield(), yield_task_fair() 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 cfs_rq->sum_w_vruntime, breaks EEVDF eligibility      calculation, and can eventually make all entities appear ineligible.      pick_next_entity() 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 yield_task_fair() 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 yield_task_fair() copied it into vruntime.  rel_deadline is only meaningful when se->deadline really carries a relative deadline that still needs to be placed against vruntime. A freshly forked sched_entity should not inherit or retain this state. Clear se->rel_deadline in __sched_fork(), together with the other sched_entity runtime state, so that the first enqueue does not interpret the new entity's deadline as a stale relative deadline.