CVE-2021-47584: iocost: Fix divide-by-zero on donation from low hweight cgroup
In the Linux kernel, the following vulnerability has been resolved:
iocost: Fix divide-by-zero on donation from low hweight cgroup
The donation calculation logic assumes that the donor has non-zero
after-donation hweight, so the lowest active hweight a donating cgroup can
have is 2 so that it can donate 1 while keeping the other 1 for itself.
Earlier, we only donated from cgroups with sizable surpluses so this
condition was always true. However, with the precise donation algorithm
implemented, f1de2439ec43 ("blk-iocost: revamp donation amount
determination") made the donation amount calculation exact enabling even low
hweight cgroups to donate.
This means that in rare occasions, a cgroup with active hweight of 1 can
enter donation calculation triggering the following warning and then a
divide-by-zero oops.
WARNING: CPU: 4 PID: 0 at block/blk-iocost.c:1928 transfer_surpluses.cold+0x0/0x53 [884/94867]
...
RIP: 0010:transfer_surpluses.cold+0x0/0x53
Code: 92 ff 48 c7 c7 28 d1 ab b5 65 48 8b 34 25 00 ae 01 00 48 81 c6 90 06 00 00 e8 8b 3f fe ff 48 c7 c0 ea ff ff ff e9 95 ff 92 ff <0f> 0b 48 c7 c7 30 da ab b5 e8 71 3f fe ff 4c 89 e8 4d 85 ed 74 0
4
...
Call Trace:
<IRQ>
ioc_timer_fn+0x1043/0x1390
call_timer_fn+0xa1/0x2c0
__run_timers.part.0+0x1ec/0x2e0
run_timer_softirq+0x35/0x70
...
iocg: invalid donation weights in /a/b: active=1 donating=1 after=0
Fix it by excluding cgroups w/ active hweight < 2 from donating. Excluding
these extreme low hweight donations shouldn't affect work conservation in
any meaningful way.
Security readout for executives and security teams
Plain-English summary
This Linux kernel flaw can crash a system under a rare block I/O control-group accounting condition. The issue is a divide-by-zero in the iocost donation logic when a very low-weight cgroup donates all remaining weight. Business impact is primarily availability risk, not confirmed data theft or privilege escalation.
Executive priority
Treat as a planned availability patch unless affected hosts are business-critical or heavily use cgroup I/O controls. There is no provided evidence of active exploitation, but a kernel crash can still create operational disruption.
Technical view
In blk-iocost, precise donation calculation allowed a cgroup with active hweight 1 to enter donation logic, leaving after-donation hweight 0 and triggering a divide-by-zero oops. The kernel fix excludes cgroups with active hweight below 2 from donating. Sources do not provide CVSS, CWE, or exploitability details.
Likely exposure
Exposure is most relevant to Linux systems using cgroups and the blk-iocost controller. The bundle identifies Linux kernel versions around 5.10, 5.15, and 5.16, but version-range evidence is incomplete and should be checked against distribution advisories.
Exploitation context
The source bundle does not show active exploitation, and KEV status is false. The described failure happens in rare low-weight cgroup donation conditions and results in a warning followed by a divide-by-zero kernel oops.
Researcher notes
The root condition is active hweight below 2 entering donation calculation after commit f1de2439ec43 changed donation determination. The public description names the fix behavior but does not provide CVSS, CWE mapping, exploit prerequisites, or distribution-specific package status.
Mitigation direction
Apply vendor or distribution kernel updates containing the referenced stable fixes.
Check Linux distribution advisories for exact affected and fixed package versions.
Prioritize systems using cgroup-based block I/O control or container workloads.
If patching is delayed, review vendor guidance for operational workarounds.
Validation and detection
Inventory Linux kernel versions across servers, hosts, and container platforms.
Check whether blk-iocost and cgroup I/O control are enabled or used.
Review kernel logs for iocost warnings or divide-by-zero oops messages.
Confirm installed kernels include the relevant upstream stable fix commits.
Generated from the cited source records. This long-tail analysis has not been individually reviewed by a named human.
Potential ATT&CK relevance
Conservative CVE-to-ATT&CK context
These mappings and lookup hints may be relevant to the vulnerability behavior, CWE, affected product, or exposure path. Glexia-inferred context is not an official MITRE, ATT&CK, CWE, or CVE Program mapping.
ATT&CK lookup starting points
Use these exact CWE pages and searches to review the Glexia ATT&CK library from this CVE's weakness and description context.
cve · low confidence lookup
CVE-2021-47584 mapping review
Open the CVE-to-ATT&CK bridge for reviewed, inferred, or future official mappings tied to this CVE.
These fields come from the CVE record and ADP containers, not from Glexia's Take. They preserve time-varying source decisions such as CISA SSVC, KEV status, CVSS metrics, and provider references.