CVE-2022-49164

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> powerpc/tm: Fix more userspace r13 corruption<br /> <br /> Commit cf13435b730a ("powerpc/tm: Fix userspace r13 corruption") fixes a<br /> problem in treclaim where a SLB miss can occur on the<br /> thread_struct-&gt;ckpt_regs while SCRATCH0 is live with the saved user r13<br /> value, clobbering it with the kernel r13 and ultimately resulting in<br /> kernel r13 being stored in ckpt_regs.<br /> <br /> There is an equivalent problem in trechkpt where the user r13 value is<br /> loaded into r13 from chkpt_regs to be recheckpointed, but a SLB miss<br /> could occur on ckpt_regs accesses after that, which will result in r13<br /> being clobbered with a kernel value and that will get recheckpointed and<br /> then restored to user registers.<br /> <br /> The same memory page is accessed right before this critical window where<br /> a SLB miss could cause corruption, so hitting the bug requires the SLB<br /> entry be removed within a small window of instructions, which is<br /> possible if a SLB related MCE hits there. PAPR also permits the<br /> hypervisor to discard this SLB entry (because slb_shadow-&gt;persistent is<br /> only set to SLB_NUM_BOLTED) although it&amp;#39;s not known whether any<br /> implementations would do this (KVM does not). So this is an extremely<br /> unlikely bug, only found by inspection.<br /> <br /> Fix this by also storing user r13 in a temporary location on the kernel<br /> stack and don&amp;#39;t change the r13 register from kernel r13 until the RI=0<br /> critical section that does not fault.<br /> <br /> The SCRATCH0 change is not strictly part of the fix, it&amp;#39;s only used in<br /> the RI=0 section so it does not have the same problem as the previous<br /> SCRATCH0 bug.