| From bippy-5f407fcff5a0 Mon Sep 17 00:00:00 2001 |
| From: Greg Kroah-Hartman <gregkh@linuxfoundation.org> |
| To: <linux-cve-announce@vger.kernel.org> |
| Reply-to: <cve@kernel.org>, <linux-kernel@vger.kernel.org> |
| Subject: CVE-2022-49164: powerpc/tm: Fix more userspace r13 corruption |
| |
| Description |
| =========== |
| |
| In the Linux kernel, the following vulnerability has been resolved: |
| |
| powerpc/tm: Fix more userspace r13 corruption |
| |
| Commit cf13435b730a ("powerpc/tm: Fix userspace r13 corruption") fixes a |
| problem in treclaim where a SLB miss can occur on the |
| thread_struct->ckpt_regs while SCRATCH0 is live with the saved user r13 |
| value, clobbering it with the kernel r13 and ultimately resulting in |
| kernel r13 being stored in ckpt_regs. |
| |
| There is an equivalent problem in trechkpt where the user r13 value is |
| loaded into r13 from chkpt_regs to be recheckpointed, but a SLB miss |
| could occur on ckpt_regs accesses after that, which will result in r13 |
| being clobbered with a kernel value and that will get recheckpointed and |
| then restored to user registers. |
| |
| The same memory page is accessed right before this critical window where |
| a SLB miss could cause corruption, so hitting the bug requires the SLB |
| entry be removed within a small window of instructions, which is |
| possible if a SLB related MCE hits there. PAPR also permits the |
| hypervisor to discard this SLB entry (because slb_shadow->persistent is |
| only set to SLB_NUM_BOLTED) although it's not known whether any |
| implementations would do this (KVM does not). So this is an extremely |
| unlikely bug, only found by inspection. |
| |
| Fix this by also storing user r13 in a temporary location on the kernel |
| stack and don't change the r13 register from kernel r13 until the RI=0 |
| critical section that does not fault. |
| |
| The SCRATCH0 change is not strictly part of the fix, it's only used in |
| the RI=0 section so it does not have the same problem as the previous |
| SCRATCH0 bug. |
| |
| The Linux kernel CVE team has assigned CVE-2022-49164 to this issue. |
| |
| |
| Affected and fixed versions |
| =========================== |
| |
| Issue introduced in 3.9 with commit 98ae22e15b430bfed5def01ac1a88ec9396284c8 and fixed in 5.15.54 with commit 5dce84f475d13b773a1a4c823581cab25044d86a |
| Issue introduced in 3.9 with commit 98ae22e15b430bfed5def01ac1a88ec9396284c8 and fixed in 5.17.2 with commit 73d8082c90f17dfba57cad4ca94db5cae323f1b1 |
| Issue introduced in 3.9 with commit 98ae22e15b430bfed5def01ac1a88ec9396284c8 and fixed in 5.18 with commit 9d71165d3934e607070c4e48458c0cf161b1baea |
| |
| Please see https://www.kernel.org for a full list of currently supported |
| kernel versions by the kernel community. |
| |
| Unaffected versions might change over time as fixes are backported to |
| older supported kernel versions. The official CVE entry at |
| https://cve.org/CVERecord/?id=CVE-2022-49164 |
| will be updated if fixes are backported, please check that for the most |
| up to date information about this issue. |
| |
| |
| Affected files |
| ============== |
| |
| The file(s) affected by this issue are: |
| arch/powerpc/kernel/tm.S |
| |
| |
| Mitigation |
| ========== |
| |
| The Linux kernel CVE team recommends that you update to the latest |
| stable kernel version for this, and many other bugfixes. Individual |
| changes are never tested alone, but rather are part of a larger kernel |
| release. Cherry-picking individual commits is not recommended or |
| supported by the Linux kernel community at all. If however, updating to |
| the latest release is impossible, the individual changes to resolve this |
| issue can be found at these commits: |
| https://git.kernel.org/stable/c/5dce84f475d13b773a1a4c823581cab25044d86a |
| https://git.kernel.org/stable/c/73d8082c90f17dfba57cad4ca94db5cae323f1b1 |
| https://git.kernel.org/stable/c/9d71165d3934e607070c4e48458c0cf161b1baea |
