CVE-2026-93182: sched/fair: Fix overflow in update_tg_cfs_runnable()
In the Linux kernel, the following vulnerability has been resolved:
sched/fair: Fix overflow in updatetgcfsrunnable()
A divide-by-zero crash is observed when running hackbench:
[14697.488452] CPU: 112 UID: 0 PID: 124791 Comm: hackbench Not tainted 7.1.0-rc2+ [14697.492627] RIP: 0010:propagateentityloadavg+0x35f/0x3e0 [14697.506799] <TASK> [14697.507411] dequeuetask+0x2b4/0xc70 [14697.508677] dequeuetaskfair+0x36/0x370 [14697.509047] dequeuetask+0x101/0x2f0 [14697.509426] schedule+0x1b1/0x1a00 [14697.510868] anonpiperead+0x3da/0x450 [14697.511400] vfsread+0x361/0x390 [14697.512053] x64sysread+0x19/0x30
The divide-by-zero happens here:
if (scaleloaddown(gcfsrq->load.weight)) { loadsum = divu64(gcfsrq->avg.loadsum, scaleloaddown(gcfsrq->load.weight)); }
gcfsrq->load.weight is an insane large value and is truncated to the lower 32 bits by divu64, which happen to be 0.
Using AI for investigation, the cause is a u32 overflow in updatetgcfsrunnable(), and flat pickup became a victim when using tgtasks():
u32 newsum, divider; ... newsum = se->avg.runnableavg divider; <-- boom
The following sequence shows how this triggers the crash:
propagateentityloadavg() updatetgcfsrunnable() # u32 overflow corrupts runnablesum
updateloadavgcfsrq() updateloadavg() # computes insane runnableavg updatetgloadavg() # propagates to tg->runnableavg
updatecfsgroup() calcconcurshares() tgtasks() # long-to-int truncation, negative nr reweightentity() # corrupted se->load.weight updateloadadd() # corrupted cfsrq->load.weight
propagateentityloadavg() updatetgcfsload() divu64() # divide-by-zero
Fix by widening newsum from u32 to u64 (no need to force tgtasks() to return unsigned long after this fix)
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
Linux kernel (sched/fair)to a version that resolves this vulnerability.Fixed in 7.1.0-rc2+
Event History
Frequently Asked Questions
What operational symptom should responders look for?
The reported failure is a divide-by-zero kernel crash in propagate_entity_load_avg during task dequeue and scheduling. The example stack includes __dequeue_task, dequeue_task_fair, __schedule, and anon_pipe_read.
What workload has been observed to trigger the issue?
The crash was observed while running hackbench. The provided information does not establish other triggering workloads, required privileges, or remote exploitability.