"value":"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]->emergency_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->kstack, 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."
