Skip to content
Fencer Vulns
high 7.8

CVE-2021-47553 json

sched/scs: Reset task stack state in bringup_cpu()

published 2024-05-24 2 y ago modified 2026-06-17 4 mo ago also EUVD-2021-34555

cvss
7.8
version 3.1, NVD
cisa kev
Not listed
not in CISA's catalog
epss
0.3%
EPSS 0.3% chance of exploitation in 30 days, percentile 17%
public exploits
0
none known

Summary

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

Patch / fix

  • Linux Linux 5.10.83, 5.13, 5.14, 5.15.6, 5.16
  • linux Debian 14, Debian 13, Debian 12 5.15.15-1

debian advisories DEBIAN-CVE-2021-47553

  • dtb-aarch64 openSUSE Leap 15.5 5.14.21-150500.55.68.1
  • kernel-64kb SLE Module for Basesystem 15 SP5, openSUSE Leap 15.5 5.14.21-150500.55.68.1
  • kernel-syms SLE Module for Development Tools 15 SP5, openSUSE Leap 15.5 5.14.21-150500.55.68.1
  • kernel-obs-qa openSUSE Leap 15.5 5.14.21-150500.55.68.1
  • kernel-source SLE Module for Development Tools 15 SP5, SLE Module for Basesystem 15 SP5, openSUSE Leap 15.5 5.14.21-150500.55.68.1
  • kernel-default SLE Workstation Extension 15 SP5, SLE Module for Legacy 15 SP5, SLE Module for Basesystem 15 SP5 +4 more 5.14.21-150500.55.68.1
  • kernel-kvmsmall openSUSE Leap 15.5 5.14.21-150500.55.68.1
  • kernel-zfcpdump SLE Module for Basesystem 15 SP5, openSUSE Leap 15.5 5.14.21-150500.55.68.1

suse advisories SUSE-SU-2024:2190-1SUSE-SU-2024:2189-1SUSE-SU-2024:2019-1SUSE-SU-2024:2011-1SUSE-SU-2024:2008-1

Vendor advisories

What the vendors themselves say about their products: affected, fixed or not affected, and what to do.

red hat product security vex CVE-2021-47553 updated cvss 6.1

kernel: sched/scs: Reset task stack state in bringup_cpu()

  • Red Hat Enterprise Linux 6 perf, kernel, python-perf, kernel-kdump, kernel-firmware, kernel-bootwrapper, +1 more Red Hat Enterprise Linux 7 perf, kernel, bpftool, kernel-rt, python-perf, kernel-kdump, +8 more
    affected: no fix planned “Out of support scope”
  • Red Hat Enterprise Linux 8 perf, kernel, bpftool, kernel-rt, kernel-core, kernel-tools, +29 more Red Hat Enterprise Linux 9 rv, perf, rtla, kernel, bpftool, libperf, +83 more
    not affected: vulnerable code not present

Red Hat CSAF VEX © Red Hat, Inc., from https://security.access.redhat.com/data/csaf/v2/vex/; changed: reduced to product statuses and remediations. CC BY 4.0 · csaf

CISA SSVC

Exploitation
none
Automatable
no
Technical impact
partial
Assessed
2 y ago

Exploit prediction

0.26% chance of exploitation in the next 30 days, higher than 17% of all scored CVEs (FIRST EPSS, 2026-11-08).

CVSS scores

assigned by version score vector
NVD 3.1 7.8 CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H

Affected products

  • Linux Linux

Classification

Weakness
  • CWE-908 Use of Uninitialized Resource
Technology feeds

References

Sources

Fencer Vulns keeps one entry per vulnerability: the CVE id wins, then GHSA, and records that alias each other are merged, except that two CVEs always keep separate entries. The same data is available as JSON.