LiveActive security incident?Get immediate response
CVE Record

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

UnknownCVSS not scoredNot KEV-listedUpdated
Glexia's TakeAutomated analysisunknown

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.
Prepared
Confidence
medium
Sources
5

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.

Open ATT&CK lookup
Vulnerability profileCVE Program record
Severity
Unknown
CVSS
Not scored
Known Exploited
No
Published
Official CVE source material

CNA and ADP enrichment extracted from CVE v5

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.

0CVSS vectors
3Timeline events
2ADP providers
4Source links

SSVC decision data

CISA-ADPCISA Coordinator
Timestamp
Version
2.0.3
Exploitation: noneAutomatable: noTechnical Impact: partial

Vulnerability timeline

Timeline events are normalized from CVE metadata, CNA source timelines, ADP timelines, and KEV metadata when present.

  1. CVE reservedCVE Program

    The CVE ID was reserved by the assigning CNA.

  2. CVE publishedCVE Program

    The CVE record was published.

  3. CVE updatedCVE Program

    The CVE record metadata indicates this as the latest update time.

ADP provider summaries

CISA-ADPCISA ADP Vulnrichment
other:ssvc
CVECVE Program Container
Affected products

Products and packages named in the record

VendorProductVersion / packageStatus
LinuxLinux3c51d82d0b7862d7d246016c74b4390fb1fa1f11, f1a0a376ca0c4ef1fc3d24e3e502acbb5b795674, f1a0a376ca0c4ef1fc3d24e3e502acbb5b795674, 1cb358b3ac1bb43aa8c4283830a84216dda65d39, 24c79a7e54ccfa29fb8cbf7ed8d1e48ff1ec6e3dunaffected
LinuxLinux5.14, 0, 5.10.83, 5.15.6, 5.16affected
Weakness

CWE details

No CWE listed

CWE links open Glexia weakness intelligence pages with official CWE context, developer remediation guidance, and related CVE mappings.