CVE-2020-11669: Linux kernel 4.10 to 5.1: powerpc: guest can cause DoS on POWER9 KVM hosts

CVE-2020-11669: Linux kernel 4.10 to 5.1: powerpc: guest can cause DoS on POWER9 KVM hosts

[Andrew Donnellan]

The Linux kernel for powerpc from v4.10 to v5.1 has a bug where the 
Authority Mask Register (AMR), Authority Mask Override Register (AMOR) 
and User Authority Mask Override Register (UAMOR) are not correctly 
saved and restored when the CPU is going into/coming out of idle state.

On POWER9 CPUs, this means that a CPU may return from idle with the AMR 
value of another thread on the same core.

This allows a trivial Denial of Service attack against KVM hosts, by 
booting a guest kernel which makes use of the AMR, such as a v5.2 or 
later kernel with Kernel Userspace Access Prevention (KUAP) enabled.

The guest kernel will set the AMR to prevent userspace access, then the 
thread will go idle. At a later point, the hardware thread that the 
guest was using may come out of idle and start executing in the host, 
without restoring the host AMR value. The host kernel can get caught in 
a page fault loop, as the AMR is unexpectedly causing memory accesses to 
fail in the host, and the host is eventually rendered unusable.

The fix is to correctly save and restore the AMR in the idle state 
handling code.

The bug does not affect POWER8 or earlier Power CPUs.

CVE-2020-11669 has been assigned.

The bug has already been fixed upstream in kernels v5.2 onwards, by [0].

Fixes have been submitted for inclusion in upstream stable kernel trees 
for v4.19[1] and v4.14[2].

The bug is already fixed in Red Hat Enterprise Linux 8 kernels from 
4.18.0-147 onwards - see RHSA-2019:3517[3].

Thanks to David Gibson of Red Hat for the initial bug report.

[0] 
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=53a712bae5dd919521a58d7bad773b949358add0

[1] https://lists.ozlabs.org/pipermail/linuxppc-dev/2020-April/208661.html

[2] https://lists.ozlabs.org/pipermail/linuxppc-dev/2020-April/208660.html

[3] https://access.redhat.com/errata/RHSA-2019:3517

-- 
Andrew Donnellan              OzLabs, ADL Canberra
ajd@linux.ibm.com             IBM Australia Limited

Re: CVE-2020-11669: Linux kernel 4.10 to 5.1: powerpc: guest can cause DoS on POWER9 KVM hosts

[Michal Suchánek]

On Wed, Apr 15, 2020 at 10:52:53PM +1000, Andrew Donnellan wrote:
> The Linux kernel for powerpc from v4.10 to v5.1 has a bug where the
> Authority Mask Register (AMR), Authority Mask Override Register (AMOR) and
> User Authority Mask Override Register (UAMOR) are not correctly saved and
> restored when the CPU is going into/coming out of idle state.
> 
> On POWER9 CPUs, this means that a CPU may return from idle with the AMR
> value of another thread on the same core.
> 
> This allows a trivial Denial of Service attack against KVM hosts, by booting
> a guest kernel which makes use of the AMR, such as a v5.2 or later kernel
> with Kernel Userspace Access Prevention (KUAP) enabled.
> 
> The guest kernel will set the AMR to prevent userspace access, then the
> thread will go idle. At a later point, the hardware thread that the guest
> was using may come out of idle and start executing in the host, without
> restoring the host AMR value. The host kernel can get caught in a page fault
> loop, as the AMR is unexpectedly causing memory accesses to fail in the
> host, and the host is eventually rendered unusable.

Hello,

shouldn't the kernel restore the host registers when leaving the guest?

I recall some code exists for handling the *AM*R when leaving guest. Can
the KVM guest enter idle without exiting to host?

Thanks

Michal

Re: CVE-2020-11669: Linux kernel 4.10 to 5.1: powerpc: guest can cause DoS on POWER9 KVM hosts

[Paul Mackerras]

On Wed, Apr 15, 2020 at 04:03:29PM +0200, Michal Suchánek wrote:
> On Wed, Apr 15, 2020 at 10:52:53PM +1000, Andrew Donnellan wrote:
> > The Linux kernel for powerpc from v4.10 to v5.1 has a bug where the
> > Authority Mask Register (AMR), Authority Mask Override Register (AMOR) and
> > User Authority Mask Override Register (UAMOR) are not correctly saved and
> > restored when the CPU is going into/coming out of idle state.
> > 
> > On POWER9 CPUs, this means that a CPU may return from idle with the AMR
> > value of another thread on the same core.
> > 
> > This allows a trivial Denial of Service attack against KVM hosts, by booting
> > a guest kernel which makes use of the AMR, such as a v5.2 or later kernel
> > with Kernel Userspace Access Prevention (KUAP) enabled.
> > 
> > The guest kernel will set the AMR to prevent userspace access, then the
> > thread will go idle. At a later point, the hardware thread that the guest
> > was using may come out of idle and start executing in the host, without
> > restoring the host AMR value. The host kernel can get caught in a page fault
> > loop, as the AMR is unexpectedly causing memory accesses to fail in the
> > host, and the host is eventually rendered unusable.
> 
> Hello,
> 
> shouldn't the kernel restore the host registers when leaving the guest?

It does.  That's not the bug.

> I recall some code exists for handling the *AM*R when leaving guest. Can
> the KVM guest enter idle without exiting to host?

No, we currently never execute the "stop" instruction in guest context.

The bug occurs when a thread that is in the host goes idle and
executes the stop instruction to go to a power-saving state, while
another thread is executing inside a guest.  Hardware loses the first
thread's AMR while it is stopped, and as it happens, it is possible
for the first thread to wake up with the contents of its AMR equal to
the other thread's AMR.  This can happen even if the first thread has
never executed in the guest.

The kernel needs to save and restore AMR (among other registers)
across the stop instruction because of this hardware behaviour.
We missed the AMR initially, which is what led to this vulnerability.

Paul.