[oss-security] arm64 Linux kernel: Privilege escalation by taking control of the KVM hypervisor

[Will Deacon]

Hi all,

Whilst reviewing some proposed arm64 KVM changes, it became apparent that
the sanity checking for the KVM_SET_ON_REG ioctl() on arm64 does not
correctly handle a number of cases:

- Unaligned register accesses and accesses that span multiple
registers can bypass PSTATE sanity checking

- The PSTATE sanity checking fails to take into account the
capabilities of the physical CPU, or the configuration of
the virtual CPU

This allows an attacker with permission to create KVM-based virtual machines
to both panic the hypervisor by triggering an illegal exception return
(resulting in a DoS) and to redirect execution elsewhere within the
hypervisor with full register control, instead of causing a return to the
guest.

This has been fixed by upstream commits:

d26c25a9d19b ("arm64: KVM: Tighten guest core register access from userspace")
2a3f93459d68 ("arm64: KVM: Sanitize PSTATE.M when being set from userspace")

which are being backported and applied to all active -stable kernels.

32-bit Arm is unaffected by this issue.

There has not yet been a CVE requested for this (mainly because I don't know
how to do it).

Thanks,

Will

[Henri Salo]

Post by Will Deacon
There has not yet been a CVE requested for this (mainly because I don't know
how to do it).

Please use https://cveform.mitre.org/ thanks.

[Florian Weimer]

Post by Henri Salo

Post by Will Deacon
There has not yet been a CVE requested for this (mainly because I don't know
how to do it).

Please use https://cveform.mitre.org/ thanks.

Would DFW work as well?

<https://github.com/distributedweaknessfiling/cvelist>

I'm asking because the Rust people tried to get an ID from there, but
apparently never got a reply.

[Marcus Meissner]

Post by Florian Weimer

Post by Henri Salo

Post by Will Deacon
There has not yet been a CVE requested for this (mainly because I don't know
how to do it).

Please use https://cveform.mitre.org/ thanks.

Would DFW work as well?
<https://github.com/distributedweaknessfiling/cvelist>
I'm asking because the Rust people tried to get an ID from there, but
apparently never got a reply.

DFW is very slow to assign CVEs, Mitre is same or next-day.

Ciao, Marcus

[Seth Arnold]

Post by Florian Weimer

Post by Henri Salo

Post by Will Deacon
There has not yet been a CVE requested for this (mainly because I don't know
how to do it).

Please use https://cveform.mitre.org/ thanks.

Would DFW work as well?
<https://github.com/distributedweaknessfiling/cvelist>
I'm asking because the Rust people tried to get an ID from there, but
apparently never got a reply.

In my experience the MITRE form is significantly more reliable and faster
mechanism than the DWF form.

I realize this is perhaps a chicken-and-egg problem, where DWF might not
be fast until they get enough traffic that they have to be fast, but MITRE
is fast *today*, so any individual CVE requestor is probably better suited
to use MITRE.

Thanks

[Salvatore Bonaccorso]

Hi,

Post by Will Deacon
Hi all,
Whilst reviewing some proposed arm64 KVM changes, it became apparent that
the sanity checking for the KVM_SET_ON_REG ioctl() on arm64 does not
- Unaligned register accesses and accesses that span multiple
registers can bypass PSTATE sanity checking
- The PSTATE sanity checking fails to take into account the
capabilities of the physical CPU, or the configuration of
the virtual CPU
This allows an attacker with permission to create KVM-based virtual machines
to both panic the hypervisor by triggering an illegal exception return
(resulting in a DoS) and to redirect execution elsewhere within the
hypervisor with full register control, instead of causing a return to the
guest.
d26c25a9d19b ("arm64: KVM: Tighten guest core register access from userspace")
2a3f93459d68 ("arm64: KVM: Sanitize PSTATE.M when being set from userspace")
which are being backported and applied to all active -stable kernels.
32-bit Arm is unaffected by this issue.
There has not yet been a CVE requested for this (mainly because I don't know
how to do it).

This issue got CVE-2018-18021 assigned.

Regards,
Salvatore