CVE-2025-37821
N/A
Summary
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 eligible, so pick_eevdf() returns NULL.
- pick_next_entity() tries to dereference the return value of pick_eevdf() and crashes.
Dumping the cfs_rq states from the core dumps with drgn showed tell-tale huge vruntime ranges and bogus vlag values, and I also traced se->slice being set to U64_MAX on live systems (which was usually "benign" since the rest of the runqueue needed to be in a particular state to crash).
Fix it in dequeue_entities() by always setting slice from the first non-empty cfs_rq.
Affected Software
| Vendor | Product | Version Range | Status |
|---|---|---|---|
| Linux | Linux | aef6987d89544d63a47753cf3741cabff0b5574c < 86b37810fa1e40b93171da023070b99ccbb4ea04 | affected |
| Linux | Linux | aef6987d89544d63a47753cf3741cabff0b5574c < 50a665496881262519f115f1bfe5822f30580eb0 | affected |
| Linux | Linux | aef6987d89544d63a47753cf3741cabff0b5574c < bbce3de72be56e4b5f68924b7da9630cc89aa1a8 | affected |
| Linux | Linux | 6.12 | affected |
| Linux | Linux | 0 < 6.12 | unaffected |
| Linux | Linux | 6.12.29 <= 6.12.* | unaffected |
| Linux | Linux | 6.14.5 <= 6.14.* | unaffected |
| Linux | Linux | 6.15 <= * | unaffected |
Weaknesses
References
- https://git.kernel.org/stable/c/86b37810fa1e40b93171da023070b99ccbb4ea04
- https://git.kernel.org/stable/c/50a665496881262519f115f1bfe5822f30580eb0
- https://git.kernel.org/stable/c/bbce3de72be56e4b5f68924b7da9630cc89aa1a8
Feedback
Was this page helpful?
Glad to hear it! Please tell us how we can improve.
Sorry to hear that. Please tell us how we can improve.