{"answers":{"affected":"It affects 1 product.","exploited":"There is no known exploitation of CVE-2021-47553 in the wild and no public exploit code.","fix":"Apply the vendor's patch.","what":"CVE-2021-47553 is a high-severity memory corruption vulnerability in Linux kernel, published on 24 May 2024. It can only be exploited from the same machine or local network, with no action from the victim."},"fix_prompt":"Check this codebase for CVE-2021-47553 and fix it if it is affected.\n\nWhat it is: CVE-2021-47553 is a high-severity memory corruption vulnerability in Linux kernel, published on 24 May 2024. It can only be exploited from the same machine or local network, with no action from the victim.\nExploitation: There is no known exploitation of CVE-2021-47553 in the wild and no public exploit code.\n\nAffected product: Linux kernel. No package-level version data is available, so check the vendor advisory linked from the reference page.\n\nTask:\n1. Search the dependency manifests and lockfiles (for example package.json, package-lock.json, requirements.txt, poetry.lock, uv.lock, pom.xml, build.gradle, go.mod, Cargo.lock, Gemfile.lock) and any Dockerfiles for the affected packages, including transitive dependencies.\n2. If an affected version is in use, upgrade it to the fixed version for its release line with the project's package manager, so the lockfile is regenerated. Prefer the smallest upgrade that fixes it.\n3. If there is no fix, or the upgrade would break the build, do not guess: explain the risk and the safest workaround instead.\n4. Run the tests and summarise what changed and why.\n5. If nothing in the project is affected, say so and change nothing.\n\nReference: https://insights.sbomify.com/CVE-2021-47553/ (Markdown: https://insights.sbomify.com/CVE-2021-47553/index.md)","id":"CVE-2021-47553","markdown":"https://insights.sbomify.com/CVE-2021-47553/index.md","name":"CVE-2021-47553","record":{"aliases":["DEBIAN-CVE-2021-47553","UBUNTU-CVE-2021-47553"],"analysis":{"component_type":"kernel","fix_type":"patch","impacts":["denial_of_service"],"network_reachable":"adjacent_or_local","non_default_config":true,"product_category":"Linux kernel","requires_auth":"low_privilege","summary":"A Linux kernel flaw allows stale shadow call stack pointers to cause memory leaks and potential denial of service during CPU hotplug operations.","user_interaction":"not_required","vuln_class":"memory_corruption"},"analysis_generated_by":"qwen3.8-flash-next","assigner":"Linux","cpe":[{"product":"linux_kernel","vendor":"linux"}],"cvss":{"score":7.8,"severity":"high","source":"nvd","vector":"CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H","version":"3.1"},"cwes":[{"id":"CWE-908","name":"Use of Uninitialized Resource"}],"description":"In the Linux kernel, the following vulnerability has been resolved:\n\nsched/scs: Reset task stack state in bringup_cpu()\n\nTo hot unplug a CPU, the idle task on that CPU calls a few layers of C\ncode before finally leaving the kernel. When KASAN is in use, poisoned\nshadow is left around for each of the active stack frames, and when\nshadow call stacks are in use. When shadow call stacks (SCS) are in use\nthe task's saved SCS SP is left pointing at an arbitrary point within\nthe task's shadow call stack.\n\nWhen a CPU is offlined than onlined back into the kernel, this stale\nstate can adversely affect execution. Stale KASAN shadow can alias new\nstackframes and result in bogus KASAN warnings. A stale SCS SP is\neffectively a memory leak, and prevents a portion of the shadow call\nstack being used. Across a number of hotplug cycles the idle task's\nentire shadow call stack can become unusable.\n\nWe previously fixed the KASAN issue in commit:\n\n  e1b77c92981a5222 (\"sched/kasan: remove stale KASAN poison after hotplug\")\n\n... by removing any stale KASAN stack poison immediately prior to\nonlining a CPU.\n\nSubsequently in commit:\n\n  f1a0a376ca0c4ef1 (\"sched/core: Initialize the idle task with preemption disabled\")\n\n... the refactoring left the KASAN and SCS cleanup in one-time idle\nthread initialization code rather than something invoked prior to each\nCPU being onlined, breaking both as above.\n\nWe fixed SCS (but not KASAN) in commit:\n\n  63acd42c0d4942f7 (\"sched/scs: Reset the shadow stack when idle_task_exit\")\n\n... but as this runs in the context of the idle task being offlined it's\npotentially fragile.\n\nTo fix these consistently and more robustly, reset the SCS SP and KASAN\nshadow of a CPU's idle task immediately before we online that CPU in\nbringup_cpu(). This ensures the idle task always has a consistent state\nwhen it is running, and removes the need to so so when exiting an idle\ntask.\n\nWhenever any thread is created, dup_task_struct() will give the task a\nstack which is free of KASAN shadow, and initialize the task's SCS SP,\nso there's no need to specially initialize either for idle thread within\ninit_idle(), as this was only necessary to handle hotplug cycles.\n\nI've tested this on arm64 with:\n\n* gcc 11.1.0, defconfig +KASAN_INLINE, KASAN_STACK\n* clang 12.0.0, defconfig +KASAN_INLINE, KASAN_STACK, SHADOW_CALL_STACK\n\n... offlining and onlining CPUS with:\n\n| while true; do\n|   for C in /sys/devices/system/cpu/cpu*/online; do\n|     echo 0 \u003e $C;\n|     echo 1 \u003e $C;\n|   done\n| done","ecosystems":[],"exploits":{"exploitdb":0,"first_seen":null,"github_poc":0,"max_poc_stars":null,"metasploit":0,"nuclei":0,"refs":[],"tier":"none_known"},"has_fix":true,"headline":"sched/scs: Reset task stack state in bringup_cpu()","id":"CVE-2021-47553","indexable":true,"kev":null,"kind":"cve","links":{"ecosystem":null,"product":"linux:linux_kernel","products":["linux:linux_kernel"],"type":"memory_corruption","year":"2021"},"n_packages":0,"n_references":3,"next":{"headline":"vdpa_sim: avoid putting an uninitialized iova_domain","id":"CVE-2021-47554"},"packages":[],"prev":{"headline":"blk-mq: cancel blk-mq dispatch work in both blk_cleanup_queue and disk_release()","id":"CVE-2021-47552"},"products":["Linux"],"published":"2024-05-24","related":[{"cvss_score":8.8,"headline":"Linux Kernel Out-of-Bounds Write","id":"CVE-2026-53266","kev_date_added":"2026-09-18","published":"2026-06-25"},{"cvss_score":8.8,"headline":"Linux Kernel Improper Input Validation","id":"CVE-2013-6282","kev_date_added":"2022-09-15","published":"2013-11-19"},{"cvss_score":8.4,"headline":"Linux Kernel Heap-Based Buffer Overflow","id":"CVE-2022-0185","kev_date_added":"2024-08-21","published":"2022-02-11"},{"cvss_score":8.4,"headline":"Linux Kernel Privilege Escalation","id":"CVE-2013-2094","kev_date_added":"2022-09-15","published":"2013-05-14"},{"cvss_score":7.8,"headline":"Linux Kernel Unspecified","id":"CVE-2026-53362","kev_date_added":"2026-08-27","published":"2026-07-04"},{"cvss_score":7.8,"headline":"Linux Kernel Missing Initialization of a Variable","id":"CVE-2026-46300","kev_date_added":"2026-10-28","published":"2026-05-23"},{"cvss_score":7.8,"headline":"Linux Kernel Race Condition","id":"CVE-2025-39964","kev_date_added":"2026-09-18","published":"2025-10-13"}],"sources":[{"class":"attribution","licence":"CVE Terms of Use (MITRE)","name":"CVE List","prefix":"CVE"},{"class":"attribution","licence":"US public information, NVD API terms","name":"NVD"},{"class":"attribution","licence":"CWE Terms of Use","name":"CWE (MITRE)"},{"class":"attribution","licence":"FIRST CVSS licence","name":"CVSS (FIRST)"}],"ssvc":{"automatable":"no","exploitation":"none","technical_impact":"partial"},"state":"PUBLISHED","updated":"2026-05-23","vendors":["Linux"]},"summary":"A Linux kernel flaw allows stale shadow call stack pointers to cause memory leaks and potential denial of service during CPU hotplug operations.","url":"https://insights.sbomify.com/CVE-2021-47553/"}