{"id":"CVE-2021-47465","details":"In the Linux kernel, the following vulnerability has been resolved:\n\nKVM: PPC: Book3S HV: Fix stack handling in idle_kvm_start_guest()\n\nIn commit 10d91611f426 (\"powerpc/64s: Reimplement book3s idle code in\nC\") kvm_start_guest() became idle_kvm_start_guest(). The old code\nallocated a stack frame on the emergency stack, but didn't use the\nframe to store anything, and also didn't store anything in its caller's\nframe.\n\nidle_kvm_start_guest() on the other hand is written more like a normal C\nfunction, it creates a frame on entry, and also stores CR/LR into its\ncallers frame (per the ABI). The problem is that there is no caller\nframe on the emergency stack.\n\nThe emergency stack for a given CPU is allocated with:\n\n  paca_ptrs[i]-\u003eemergency_sp = alloc_stack(limit, i) + THREAD_SIZE;\n\nSo emergency_sp actually points to the first address above the emergency\nstack allocation for a given CPU, we must not store above it without\nfirst decrementing it to create a frame. This is different to the\nregular kernel stack, paca-\u003ekstack, which is initialised to point at an\ninitial frame that is ready to use.\n\nidle_kvm_start_guest() stores the backchain, CR and LR all of which\nwrite outside the allocation for the emergency stack. It then creates a\nstack frame and saves the non-volatile registers. Unfortunately the\nframe it creates is not large enough to fit the non-volatiles, and so\nthe saving of the non-volatile registers also writes outside the\nemergency stack allocation.\n\nThe end result is that we corrupt whatever is at 0-24 bytes, and 112-248\nbytes above the emergency stack allocation.\n\nIn practice this has gone unnoticed because the memory immediately above\nthe emergency stack happens to be used for other stack allocations,\neither another CPUs mc_emergency_sp or an IRQ stack. See the order of\ncalls to irqstack_early_init() and emergency_stack_init().\n\nThe low addresses of another stack are the top of that stack, and so are\nonly used if that stack is under extreme pressue, which essentially\nnever happens in practice - and if it did there's a high likelyhood we'd\ncrash due to that stack overflowing.\n\nStill, we shouldn't be corrupting someone else's stack, and it is purely\nluck that we aren't corrupting something else.\n\nTo fix it we save CR/LR into the caller's frame using the existing r1 on\nentry, we then create a SWITCH_FRAME_SIZE frame (which has space for\npt_regs) on the emergency stack with the backchain pointing to the\nexisting stack, and then finally we switch to the new frame on the\nemergency stack.","modified":"2026-03-15T22:43:13.912662Z","published":"2024-05-22T07:15:11.367Z","related":["SUSE-SU-2024:2008-1","SUSE-SU-2024:2010-1","SUSE-SU-2024:2011-1","SUSE-SU-2024:2019-1","SUSE-SU-2024:2183-1","SUSE-SU-2024:2185-1","SUSE-SU-2024:2189-1","SUSE-SU-2024:2190-1"],"references":[{"type":"FIX","url":"https://git.kernel.org/stable/c/6d077c37c4643394b1bae9682da48164fc147ea8"},{"type":"FIX","url":"https://git.kernel.org/stable/c/80bbb0bc3a0288442f7fe6fc514f4ee1cb06ccb7"},{"type":"FIX","url":"https://git.kernel.org/stable/c/9b4416c5095c20e110c82ae602c254099b83b72f"},{"type":"FIX","url":"https://git.kernel.org/stable/c/fbd724c49bead048ae9fc1a5b7bff2fb3e54f855"}],"affected":[{"database_specific":{"source":"https://storage.googleapis.com/cve-osv-conversion/osv-output/CVE-2021-47465.json","unresolved_ranges":[{"events":[{"introduced":"5.2"},{"fixed":"5.4.156"}]},{"events":[{"introduced":"5.5"},{"fixed":"5.10.76"}]},{"events":[{"introduced":"5.11"},{"fixed":"5.14.15"}]},{"events":[{"introduced":"0"},{"last_affected":"5.15-rc1"}]},{"events":[{"introduced":"0"},{"last_affected":"5.15-rc2"}]},{"events":[{"introduced":"0"},{"last_affected":"5.15-rc3"}]},{"events":[{"introduced":"0"},{"last_affected":"5.15-rc4"}]},{"events":[{"introduced":"0"},{"last_affected":"5.15-rc5"}]}]}}],"schema_version":"1.7.5","severity":[{"type":"CVSS_V3","score":"CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H"}]}