PT-2026-51874 · Linux · Linux

Published

2026-06-24

·

Updated

2026-06-24

·

CVE-2026-52980

None

No severity ratings or metrics are available. When they are, we'll update the corresponding info on the page.
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.
Found an issue in the description? Have something to add? Feel free to write us 👾

Related Identifiers

CVE-2026-52980

Affected Products

Linux