CVE-2025-37821: Vulnerability in Linux Linux

Severity: highType: vulnerabilityCVE-2025-37821

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: 1. 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. 2. The first for_each_sched_entity() loop dequeues the entity. 3. If the entity was its parent's only child, then the next iteration tries to dequeue the parent. 4. If the parent's dequeue needs to be delayed, then it breaks from the first for_each_sched_entity() loop _without updating slice_. 5. 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: 6. In update_entity_lag(), se->slice is used to calculate limit, which ends up as a huge negative number. 7. 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. 8. In place_entity(), se->vlag is scaled, which overflows and results in another huge (positive or negative) number. 9. The adjusted lag is subtracted from se->vruntime, which increases or decreases se->vruntime by a huge number. 10. 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. 11. Nothing appears to be eligible, so pick_eevdf() returns NULL. 12. 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.

AI Analysis

Technical Summary

CVE-2025-37821 is a vulnerability identified in the Linux kernel's Completely Fair Scheduler (CFS) implementation, specifically within the eevdf scheduling class. The flaw arises from improper handling of the 'slice' value in the dequeue_entities() function. Under certain conditions, the slice value of a sched_entity (se) can be set to U64_MAX (the maximum unsigned 64-bit integer), which leads to incorrect calculations and ultimately causes the kernel to crash. The vulnerability manifests when dequeue_entities() attempts to dequeue a delayed group entity whose parent's dequeue is also delayed. In this scenario, the slice is initially set to cfs_rq_min_slice(group_cfs_rq(se)), which returns U64_MAX if the entity has no queued tasks. The function then attempts to dequeue the entity and its parent, but if the parent's dequeue is delayed, the slice value is not updated and remains at U64_MAX. This erroneous slice value propagates through subsequent scheduling calculations, including update_entity_lag() and place_entity(), causing integer overflows and underflows. These corrupt the vruntime and vlag values used by the scheduler to determine task eligibility. The corrupted values cause pick_eevdf() to fail to select a next entity, returning NULL, which pick_next_entity() then dereferences, resulting in a kernel crash. This vulnerability can cause denial of service (DoS) by crashing the Linux kernel scheduler, impacting system stability and availability. The root cause is a logic error in slice value management during entity dequeue operations, fixed by ensuring slice is always set from the first non-empty cfs_rq. No known exploits are reported in the wild yet, but the flaw is critical due to its potential to crash systems running affected Linux kernel versions.

Potential Impact

For European organizations relying on Linux-based systems, this vulnerability poses a significant risk to system availability and operational continuity. Linux is widely used across European enterprises, government agencies, cloud providers, and critical infrastructure sectors. A kernel crash induced by this flaw can lead to unexpected system reboots or downtime, disrupting services and potentially causing data loss if unsaved work is lost during crashes. Systems running real-time or near-real-time workloads, such as telecommunications, financial trading platforms, or industrial control systems, may experience severe degradation or outages. The vulnerability does not appear to allow privilege escalation or direct data compromise but can be leveraged for denial-of-service attacks, either by local users or potentially by remote attackers if they can trigger the scheduling conditions remotely (e.g., via containerized workloads or multi-tenant environments). The impact is heightened in environments with high system load or complex scheduling scenarios where the bug is more likely to be triggered. European organizations with large Linux deployments, especially those using custom or older kernel versions, must prioritize patching to maintain service reliability and avoid operational disruptions.

Mitigation Recommendations

1. Immediate application of the official Linux kernel patch that corrects the slice value assignment in dequeue_entities() is the primary mitigation. Organizations should track kernel updates from their Linux distribution vendors and apply security updates promptly. 2. For environments where immediate patching is not feasible, consider implementing kernel live patching solutions (e.g., kpatch, ksplice) if supported, to minimize downtime. 3. Monitor system logs and kernel crash dumps for symptoms of this vulnerability, such as unusual scheduler crashes or kernel panics related to vruntime or slice values. 4. Limit untrusted or low-privileged user access to systems where possible, as local users may trigger the bug. 5. In containerized or multi-tenant environments, isolate workloads to reduce the risk of one tenant triggering the scheduler bug affecting others. 6. Conduct thorough testing of kernel updates in staging environments to ensure stability before production deployment. 7. Maintain robust backup and recovery procedures to mitigate potential data loss from unexpected crashes. 8. Engage with Linux distribution security advisories and community forums for ongoing updates and mitigation strategies.