Skip to main content

CVE-2021-47553: Vulnerability in Linux Linux

Medium
VulnerabilityCVE-2021-47553cvecve-2021-47553
Published: Fri May 24 2024 (05/24/2024, 15:09:55 UTC)
Source: CVE
Vendor/Project: Linux
Product: Linux

Description

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

AI-Powered Analysis

AILast updated: 06/28/2025, 05:25:34 UTC

Technical Analysis

CVE-2021-47553 is a vulnerability in the Linux kernel related to the handling of CPU hotplug operations, specifically concerning the management of the idle task's stack state when CPUs are offlined and then onlined. The issue arises in the kernel's scheduler code (sched/scs) where the task stack state is not properly reset in the bringup_cpu() function. When Kernel Address Sanitizer (KASAN) and Shadow Call Stacks (SCS) are enabled, stale or poisoned shadow memory and stale SCS stack pointers (SP) can remain associated with the idle task of a CPU that has been offlined. This stale state leads to memory leaks and unusable portions of the shadow call stack after multiple hotplug cycles. The vulnerability stems from a refactoring that moved KASAN and SCS cleanup code into idle thread initialization, which only runs once, rather than before each CPU online event, breaking the intended cleanup process. The fix involves resetting the SCS SP and KASAN shadow for the idle task immediately before a CPU is onlined in bringup_cpu(), ensuring consistent and clean stack state for the idle task. This prevents stale state from affecting execution and eliminates the need for fragile cleanup during idle task exit. The vulnerability does not appear to be exploitable for code execution or privilege escalation, but it can cause memory leaks and bogus KASAN warnings, potentially impacting kernel debugging and reliability during CPU hotplug operations. The issue has been tested on arm64 architectures with various compiler configurations and KASAN/SCS enabled. No known exploits are reported in the wild.

Potential Impact

For European organizations, the primary impact of CVE-2021-47553 is on system stability and reliability in environments where CPU hotplugging is used, such as in cloud infrastructure, virtualization hosts, and high-availability servers running Linux kernels with KASAN and SCS enabled. While this vulnerability does not directly lead to remote code execution or privilege escalation, it can cause memory leaks and false-positive kernel warnings that may complicate debugging and monitoring efforts. This could increase operational overhead and risk of misdiagnosis during incident response or system maintenance. Organizations relying on real-time or critical systems that dynamically manage CPU resources might experience degraded performance or unexpected behavior during CPU hotplug cycles. Since KASAN and SCS are primarily used for debugging and security hardening, production systems without these features enabled are less likely to be affected. However, development, testing, and security-hardened environments in European enterprises and research institutions could see an impact. The vulnerability underscores the importance of maintaining up-to-date kernel versions and careful management of CPU hotplug operations in Linux-based systems.

Mitigation Recommendations

1. Apply the latest Linux kernel patches that address CVE-2021-47553, ensuring the bringup_cpu() function properly resets the idle task's KASAN shadow and SCS SP before CPU online events. 2. For environments using KASAN and SCS, validate kernel versions and configurations to confirm the fix is present. 3. Limit CPU hotplug operations where possible, especially in production environments, to reduce exposure to this issue. 4. Implement monitoring for kernel warnings related to KASAN and shadow call stacks to detect potential stale state issues early. 5. In development and testing environments, ensure that kernel debugging tools are updated and configured to handle CPU hotplug cycles correctly. 6. Coordinate with Linux distribution vendors to receive timely security updates and backports for affected kernel versions. 7. Conduct thorough testing of CPU hotplug functionality after kernel upgrades to confirm system stability. 8. Consider disabling KASAN and SCS in production environments unless explicitly required, to avoid potential side effects from this vulnerability.

Need more detailed analysis?Get Pro

Technical Details

Data Version
5.1
Assigner Short Name
Linux
Date Reserved
2024-05-24T15:02:54.833Z
Cisa Enriched
true
Cvss Version
null
State
PUBLISHED

Threat ID: 682d9822c4522896dcbde15e

Added to database: 5/21/2025, 9:08:50 AM

Last enriched: 6/28/2025, 5:25:34 AM

Last updated: 8/16/2025, 12:56:33 AM

Views: 19

Actions

PRO

Updates to AI analysis are available only with a Pro account. Contact root@offseq.com for access.

Please log in to the Console to use AI analysis features.

Need enhanced features?

Contact root@offseq.com for Pro access with improved analysis and higher rate limits.

Latest Threats