CVE-2021-47553: sched/scs: Reset task stack state in bringup_cpu()
In the Linux kernel, the following vulnerability has been resolved:
sched/scs: Reset task stack state in bringup_cpu()
To hot unplug a CPU, the idle task on that CPU calls a few layers of C
code before finally leaving the kernel. When KASAN is in use, poisoned
shadow is left around for each of the active stack frames, and when
shadow call stacks are in use. When shadow call stacks (SCS) are in use
the task's saved SCS SP is left pointing at an arbitrary point within
the task's shadow call stack.
When a CPU is offlined than onlined back into the kernel, this stale
state can adversely affect execution. Stale KASAN shadow can alias new
stackframes and result in bogus KASAN warnings. A stale SCS SP is
effectively a memory leak, and prevents a portion of the shadow call
stack being used. Across a number of hotplug cycles the idle task's
entire shadow call stack can become unusable.
We previously fixed the KASAN issue in commit:
e1b77c92981a5222 ("sched/kasan: remove stale KASAN poison after hotplug")
... by removing any stale KASAN stack poison immediately prior to
onlining a CPU.
Subsequently in commit:
f1a0a376ca0c4ef1 ("sched/core: Initialize the idle task with preemption disabled")
... the refactoring left the KASAN and SCS cleanup in one-time idle
thread initialization code rather than something invoked prior to each
CPU being onlined, breaking both as above.
We fixed SCS (but not KASAN) in commit:
63acd42c0d4942f7 ("sched/scs: Reset the shadow stack when idle_task_exit")
... but as this runs in the context of the idle task being offlined it's
potentially fragile.
To fix these consistently and more robustly, reset the SCS SP and KASAN
shadow of a CPU's idle task immediately before we online that CPU in
bringup_cpu(). This ensures the idle task always has a consistent state
when it is running, and removes the need to so so when exiting an idle
task.
Whenever any thread is created, dup_task_struct() will give the task a
stack which is free of KASAN shadow, and initialize the task's SCS SP,
so there's no need to specially initialize either for idle thread within
init_idle(), as this was only necessary to handle hotplug cycles.
I've tested this on arm64 with:
* gcc 11.1.0, defconfig +KASAN_INLINE, KASAN_STACK
* clang 12.0.0, defconfig +KASAN_INLINE, KASAN_STACK, SHADOW_CALL_STACK
... offlining and onlining CPUS with:
| while true; do
| for C in /sys/devices/system/cpu/cpu*/online; do
| echo 0 > $C;
| echo 1 > $C;
| done
| done
Security readout for executives and security teams
Plain-English summary
This Linux kernel flaw can leave stale idle-task stack state after CPU hotplug cycles. In affected builds, CPU offline/online activity may cause false KASAN reports or exhaust the idle task shadow call stack. The source does not show active exploitation or a remote attack path.
Executive priority
Treat as a kernel maintenance issue unless your environment heavily uses CPU hotplug or affected debugging/hardening configurations. Schedule patch verification through normal kernel update governance.
Technical view
The fix moves KASAN shadow cleanup and Shadow Call Stack pointer reset into bringup_cpu(), immediately before a CPU is onlined. Prior refactoring left cleanup in one-time idle initialization, so hotplug cycles could reuse stale stack metadata.
Likely exposure
Exposure is likely limited to Linux kernels matching the listed affected versions or commit ranges, especially environments using CPU hotplug with KASAN or Shadow Call Stack configurations. Distribution backports may change status.
Exploitation context
The bundle marks KEV as false and provides no evidence of exploitation. The described trigger is CPU hot unplug and re-online behavior, with impacts framed as bogus diagnostics and shadow call stack capacity loss.
Researcher notes
Evidence supports a correctness flaw in idle-task state reset during CPU bringup. The source does not provide CVSS, CWE, exploitability analysis, or user-triggerable attack conditions, so risk should be validated against kernel configuration and backport status.
Mitigation direction
Update to a Linux kernel containing the referenced stable fixes.
Check distribution vendor advisories for backported kernel packages.
Prioritize systems that rely on CPU hotplug or affected kernel hardening/debug features.
Avoid assuming exposure from version alone; verify vendor patch lineage.
Validation and detection
Inventory Linux kernel versions and vendor package revisions.
Compare running kernels against the CVE record and stable commit references.
Review kernel configuration for KASAN and Shadow Call Stack usage.
Confirm whether CPU hotplug is enabled or operationally used.
Track remediation status through the distribution security channel.
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-47553 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.