In the Linux kernel, the following vulnerability has been resolved:
sched/eevdf: Fix se->slice being set to U64_MAX and resulting crash
There is a code path in dequeue_entities() that can set the slice of a
sched_entity to U64_MAX, which sometimes results in a crash.
The offending case is when dequeue_entities() is called to dequeue a
delayed group entity, and then the entity's parent's dequeue is delayed.
In that case:
- In the if (entity_is_task(se)) else block at the beginning of
dequeue_entities(), slice is set to
cfs_rq_min_slice(group_cfs_rq(se)). If the entity was delayed, then
it has no queued tasks, so cfs_rq_min_slice() returns U64_MAX.
- The first for_each_sched_entity() loop dequeues the entity.
- If the entity was its parent's only child, then the next iteration
tries to dequeue the parent.
- If the parent's dequeue needs to be delayed, then it breaks from the
first for_each_sched_entity() loop without updating slice.
- The second for_each_sched_entity() loop sets the parent's ->slice to
the saved slice, which is still U64_MAX.
This throws off subsequent calculations with potentially catastrophic
results. A manifestation we saw in production was:
- In update_entity_lag(), se->slice is used to calculate limit, which
ends up as a huge negative number.
- limit is used in se->vlag = clamp(vlag, -limit, limit). Because limit
is negative, vlag > limit, so se->vlag is set to the same huge
negative number.
- In place_entity(), se->vlag is scaled, which overflows and results in
another huge (positive or negative) number.
- The adjusted lag is subtracted from se->vruntime, which increases or
decreases se->vruntime by a huge number.
- pick_eevdf() calls entity_eligible()/vruntime_eligible(), which
incorrectly returns false because the vruntime is so far from the
other vruntimes on the queue, causing the
(vruntime - cfs_rq->min_vruntime) * load calulation to overflow.
- Nothing appears to be...