CVE-2021-46993: sched: Fix out-of-bound access in uclamp
In the Linux kernel, the following vulnerability has been resolved:
sched: Fix out-of-bound access in uclamp
Util-clamp places tasks in different buckets based on their clamp values
for performance reasons. However, the size of buckets is currently
computed using a rounding division, which can lead to an off-by-one
error in some configurations.
For instance, with 20 buckets, the bucket size will be 1024/20=51. A
task with a clamp of 1024 will be mapped to bucket id 1024/51=20. Sadly,
correct indexes are in range [0,19], hence leading to an out of bound
memory access.
Clamp the bucket id to fix the issue.
Security readout for executives and security teams
Plain-English summary
This Linux kernel issue is an off-by-one scheduler bug. Certain utilization clamp values can be placed into a bucket number outside the valid range, causing out-of-bounds memory access. The sources do not provide CVSS, impact class, or evidence of active exploitation.
Executive priority
Track this as a kernel maintenance issue until vendor severity is known. No active exploitation is cited, but kernel memory-safety bugs can have high business impact if exploitable. Include it in normal emergency patch review for Linux fleets.
Technical view
The scheduler uclamp bucket size is calculated by rounded division. With configurations such as 20 buckets, a clamp value of 1024 can map to bucket id 20 while valid indexes are 0-19. The resolved fix clamps the computed bucket id before access.
Likely exposure
Exposure is limited to Linux systems running affected kernel versions or vendor kernels carrying the vulnerable scheduler uclamp code. The CVE record names Linux kernel lines around 5.3, with stable fixes referenced for later maintained branches.
Exploitation context
No source in the bundle states public exploitation, proof-of-concept availability, or inclusion in CISA KEV. Treat exploitation status as unconfirmed. The issue is a memory-safety flaw in kernel scheduler code, so prioritize based on kernel exposure and vendor severity once available.
Researcher notes
The core condition is bucket index calculation exceeding the uclamp bucket array bounds when clamp value is maximal. The source bundle does not identify attacker prerequisites, reachable interfaces, crash behavior, privilege impact, or architecture-specific constraints.
Mitigation direction
Update to a Linux kernel version containing the referenced stable fixes.
Check distribution vendor advisories for backported kernel packages.
Prioritize internet-facing, multi-user, and container-host kernels first.
Avoid assuming unaffected status from upstream version alone; verify vendor backports.
Validation and detection
Inventory running kernel versions across servers, endpoints, and container hosts.
Map kernels against vendor advisories and the referenced stable commits.
Confirm patched package installation and reboot into the patched kernel.
Review whether custom kernels include the uclamp bucket-id clamp fix.
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-46993 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.