Xen Security Advisory 279 v3 (CVE-2018-19965) - x86: DoS from attempting to use INVPCID with a non-canonical addresses

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

            Xen Security Advisory CVE-2018-19965 / XSA-279
                              version 3

 x86: DoS from attempting to use INVPCID with a non-canonical addresses

UPDATES IN VERSION 3
====================

CVE assigned.

ISSUE DESCRIPTION
=================

The INVPCID instruction raises #GP[0] if an attempt is made to
invalidate a non-canonical address.  Older flushing mechanisms such as
INVLPG tolerate this without error, and perform no action.

There is one guest accessible path in Xen where a non-canonical
address was passed into the TLB flushing code.  This previously had no
ill effect, but became vulnerable with the introduction of PCID to
reduce the performance hit from the Meltdown mitigations.

IMPACT
======

A buggy or malicious PV guest can crash the host.

VULNERABLE SYSTEMS
==================

Only hardware which supports the INVPCID instruction is vulnerable.  This is
available on Intel Haswell processors and later.  AMD x86 processors are not
known to support this instruction, and ARM processors are entirely unaffected.

Only versions of Xen with PCID support are vulnerable.  Support first appeared
in Xen 4.11 but was backported to the stable trees as part of the Meltdown
(XSA-254 / CVE-2017-5754) fixes.  Xen 4.10.2, 4.9.3, 4.8.4 as well as the
stable-4.7 and 4.6 branches are vulnerable.

The vulnerability is only exposed to 64-bit PV guests.  32-bit PV guests, as
well as HVM/PVH guests cannot exploit the vulnerability.

MITIGATION
==========

Booting Xen with `pcid=0` or `invpcid=0` on the command line will work around
the issue.  Alternatively, running untrusted 64bit PV guests inside xen-shim
will work around the issue.

CREDITS
=======

This issue was discovered by Matthew Daley.

RESOLUTION
==========

Applying the appropriate attached patch resolves this issue.

xsa279.patch             xen-unstable, Xen 4.11.x, Xen 4.10.x
xsa279-4.9.patch         Xen 4.9.x ... 4.7.x

$ sha256sum xsa279*
40319fcf33348176eb14d7fc7c68c255cc7291013242ea444de6d00602024a11  xsa279.meta
0c1d50effe6645051a15dd83af57088dd4a055e26a23b1fa9e6c3722a7973f5d  xsa279.patch
fd34f29bc7e53359585135408cbbd12e12a003f59b135e81cc44186c5cddd40d  xsa279-4.9.patch
$

DEPLOYMENT DURING EMBARGO
=========================

Deployment of the patches and/or mitigations described above (or
others which are substantially similar) is permitted during the
embargo, even on public-facing systems with untrusted guest users and
administrators.

But: Distribution of updated software is prohibited (except to other
members of the predisclosure list).

Predisclosure list members who wish to deploy significantly different
patches and/or mitigations, please contact the Xen Project Security
Team.


(Note: this during-embargo deployment notice is retained in
post-embargo publicly released Xen Project advisories, even though it
is then no longer applicable.  This is to enable the community to have
oversight of the Xen Project Security Team's decisionmaking.)

For more information about permissible uses of embargoed information,
consult the Xen Project community's agreed Security Policy:
  http://www.xenproject.org/security-policy.html
-----BEGIN PGP SIGNATURE-----

iQFABAEBCAAqFiEEI+MiLBRfRHX6gGCng/4UyVfoK9kFAlw00zAMHHBncEB4ZW4u
b3JnAAoJEIP+FMlX6CvZn0EH/0hSD6EUH7AyxFOCgPtaeOiRG0NPmGcnsVcHogU2
ows3sG+6+VenzyMdf0FcEqSEnCfFbQgqGuMaKE4U4ngSWWg+hdUhJ/5T/rMQv7o1
QJ84xhKRRHrAju1WZWdACZJpq7vAOiJmkS9HvkxjFw8J2ck+8KakyInLA1AlHC+K
8cApZtqxEyCNvH9w1Ho3PNtcNGhI6ZNxYlSSSUIfLz+dI7EXGQer2FiPzwE/KdAi
vp0+61HotZ3mz03AZOelzJK7tmP5a8/u+zZfwfEw9s6zEO1RadUCHM3FIiZrSJLk
v4si1s8x+FdbYwaHBKQGQTl6IQD/URqiK2IdWYdbeTkVCKY=
=COoK
-----END PGP SIGNATURE-----

_______________________________________________
Xen-announce mailing list
[email protected]
https://lists.xenproject.org/mailman/listinfo/xen-announce

From: Andrew Cooper <[email protected]>
Subject: x86/mm: Don't perform flush after failing to update a guests L1e

If the L1e update hasn't occured, the flush cannot do anything useful.  This
skips the potentially expensive vcpumask_to_pcpumask() conversion, and
broadcast TLB shootdown.

More importantly however, we might be in the error path due to a bad va
parameter from the guest, and this should not propagate into the TLB flushing
logic.  The INVPCID instruction for example raises #GP for a non-canonical
address.

This is XSA-279.

Reported-by: Matthew Daley <[email protected]>
Signed-off-by: Andrew Cooper <[email protected]>
Reviewed-by: Jan Beulich <[email protected]>

diff --git a/xen/arch/x86/mm.c b/xen/arch/x86/mm.c
index 703f330..75663c6 100644
--- a/xen/arch/x86/mm.c
+++ b/xen/arch/x86/mm.c
@@ -4155,6 +4155,14 @@ static int __do_update_va_mapping(
     if ( pl1e )
         unmap_domain_page(pl1e);
 
+    /*
+     * Any error at this point means that we haven't change the L1e.  Skip the
+     * flush, as it won't do anything useful.  Furthermore, va is guest
+     * controlled and not necesserily audited by this point.
+     */
+    if ( rc )
+        return rc;
+
     switch ( flags & UVMF_FLUSHTYPE_MASK )
     {
     case UVMF_TLB_FLUSH:

From: Andrew Cooper <[email protected]>
Subject: x86/mm: Don't perform flush after failing to update a guests L1e

If the L1e update hasn't occured, the flush cannot do anything useful.  This
skips the potentially expensive vcpumask_to_pcpumask() conversion, and
broadcast TLB shootdown.

More importantly however, we might be in the error path due to a bad va
parameter from the guest, and this should not propagate into the TLB flushing
logic.  The INVPCID instruction for example raises #GP for a non-canonical
address.

This is XSA-279.

Reported-by: Matthew Daley <[email protected]>
Signed-off-by: Andrew Cooper <[email protected]>
Reviewed-by: Jan Beulich <[email protected]>

--- a/xen/arch/x86/mm.c
+++ b/xen/arch/x86/mm.c
@@ -4894,6 +4894,14 @@ static int __do_update_va_mapping(
     if ( pl1e )
         guest_unmap_l1e(pl1e);
 
+    /*
+     * Any error at this point means that we haven't change the l1e.  Skip the
+     * flush, as it won't do anything useful.  Furthermore, va is guest
+     * controlled and not necesserily audited by this point.
+     */
+    if ( rc )
+        return rc;
+
     switch ( flags & UVMF_FLUSHTYPE_MASK )
     {
     case UVMF_TLB_FLUSH: