[prev in list] [next in list] [prev in thread] [next in thread]
List: oss-security
Subject: [oss-security] Xen Security Advisory 279 v2 - x86: DoS from attempting to use INVPCID with a non-can
From: Xen.org security team <security () xen ! org>
Date: 2018-11-20 13:26:28
Message-ID: E1gP62u-0000f9-0t () xenbits ! xenproject ! org
[Download RAW message or body]
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Xen Security Advisory XSA-279
version 2
x86: DoS from attempting to use INVPCID with a non-canonical addresses
UPDATES IN VERSION 2
====================
Public release.
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/4UyVfoK9kFAlv0C2oMHHBncEB4ZW4u
b3JnAAoJEIP+FMlX6CvZKtwH/iNT0SP+by+n+HfWJfl4hZgJ4ZU3ZJDXyxuMchHv
ZXYxW9FEab34qjOtRKToIYaPybjULbCNf2EeSmdwuHS55BP+GlnGT27gCU0FSECJ
bfCkXFAJh04SjjzInOQxyfMUPmCztnwQvzADPJkxp1+nc++9P66Y44AwzUrRHsT1
A/dryLbZP/WiFyfYBnBPeh8Ib2eaAA1cxWLVbHwYlrrzgwf8pLHtKObW1TiSS/gr
inPqwvcU3dwj3OnsB2KuWodgP7cN/YyE/pdCiSiR7xZqcWN5/bdodwARhGTc2XY3
2OLodVSz962xjmCku7YN0ntiuU1C/c7w2dT5KsF9H/mPwl4=
=f39b
-----END PGP SIGNATURE-----
["xsa279.meta" (application/octet-stream)]
["xsa279.patch" (application/octet-stream)]
From: Andrew Cooper <andrew.cooper3@citrix.com>
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 <mattd@bugfuzz.com>
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
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:
["xsa279-4.9.patch" (application/octet-stream)]
From: Andrew Cooper <andrew.cooper3@citrix.com>
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 <mattd@bugfuzz.com>
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
--- 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:
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic