[prev in list] [next in list] [prev in thread] [next in thread]
List: oss-security
Subject: [oss-security] Xen Security Advisory 259 (CVE-2018-10471) - x86: PV guest may crash Xen with XPTI
From: Xen.org security team <security () xen ! org>
Date: 2018-04-30 13:16:35
Message-ID: E1fD8fT-0007wS-Ti () xenbits ! xenproject ! org
[Download RAW message or body]
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Xen Security Advisory CVE-2018-10471 / XSA-259
version 3
x86: PV guest may crash Xen with XPTI
UPDATES IN VERSION 3
====================
CVE assigned.
ISSUE DESCRIPTION
=================
The workaround for the Meltdown vulnerability (XSA-254) failed to deal
with an error code path connecting the INT 80 handling with general
exception handling. This results in an unconditional write attempt of
the value zero to an address near 2^64, in cases where a PV guest has no
handler installed for INT 80 on one of its vCPU-s.
IMPACT
======
A malicious or buggy guest may cause a hypervisor crash, resulting in
a Denial of Service (DoS) affecting the entire host.
VULNERABLE SYSTEMS
==================
All Xen versions which the XSA-254 fixes were applied to are vulnerable.
Only x86 systems are vulnerable. ARM systems are not vulnerable.
Only x86 PV guests can exploit the vulnerability. x86 PVH and HVM
guests cannot exploit the vulnerability.
MITIGATION
==========
Running only PVH or HVM guests avoids the vulnerability.
CREDITS
=======
This issue was discovered by Andrew Cooper of Citrix.
RESOLUTION
==========
Applying the appropriate attached patch resolves this issue.
xsa259.patch xen-unstable, Xen 4.10.x ... xen 4.7.x
xsa259-4.6.patch Xen 4.6.x
$ sha256sum xsa259*
5c14a90af066c952974324b361e2a428c280f876b854f0c85a78e8579054a4d1 xsa259.meta
ff2efb5eb2502ded988d0aa15351030a15494a9e2223eafbb88377a8e4d39dcb xsa259.patch
c40bc8802077cf73f8393fb50574b7c7efbc4d127e202b0ebd757d34aa07aac3 xsa259-4.6.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-----
Version: GnuPG v1
iQEcBAEBCAAGBQJa5xa0AAoJEIP+FMlX6CvZDGEIAL5KbzcBUVjNsguU0HQ2Q6k8
WejwrXdKkncObK3yoxuybDE4NS+A5o0FbhdpJ86ukemZd2pMutgz79Z14UhSiURk
Owdj7BlzD64O42OftKqXiNKVp4QhOlOh02TU08Q4m6GKAtCi+HlBcK8EQFR8URhX
E2zLtpqGv5z6qx26raTDWQAssak4qL/NPSQ7oc3Eqo7P7H8B3Jw+F7DoR9a1g2ye
gwuINHuk0ea9+jLoinNTDDn17xDAwp8KHPGrI/ivlwGyFipBISICdReDHe/EfIWS
BNvrZl4ccDe95B1SosN8d0/qGYPLfpSN910hmm0ZTit0XffDseLv/odxoLuDvuQ=
=clOX
-----END PGP SIGNATURE-----
["xsa259.meta" (application/octet-stream)]
["xsa259.patch" (application/octet-stream)]
From: Jan Beulich <jbeulich@suse.com>
Subject: x86: fix slow int80 path after XPTI additions
For the int80 slow path to jump to handle_exception_saved, %r14 needs to
be set up suitably for XPTI purposes. This is because of the difference
in nature between the int80 path (which is synchronous WRT guest
actions) and the exception path which is potentially asynchronous.
This is XSA-259.
Reported-by: Andrew Cooper <andrew.cooper3@citrix.com>
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
--- a/xen/arch/x86/x86_64/entry.S
+++ b/xen/arch/x86/x86_64/entry.S
@@ -396,6 +396,12 @@ int80_slow_path:
movl $TRAP_gp_fault,UREGS_entry_vector(%rsp)
/* A GPF wouldn't have incremented the instruction pointer. */
subq $2,UREGS_rip(%rsp)
+ /*
+ * While we've cleared xen_cr3 above already, normal exception handling
+ * code has logic to restore the original value from %r15. Therefore we
+ * need to set up %r14 here, while %r15 is required to still be zero.
+ */
+ GET_STACK_END(14)
jmp handle_exception_saved
/* create_bounce_frame & helpers don't need to be in .text.entry */
["xsa259-4.6.patch" (application/octet-stream)]
From: Jan Beulich <jbeulich@suse.com>
Subject: x86: fix slow int80 path after XPTI additions
For the int80 slow path to jump to handle_exception_saved, %r14 needs to
be set up suitably for XPTI purposes. This is because of the difference
in nature between the int80 path (which is synchronous WRT guest
actions) and the exception path which is potentially asynchronous.
This is XSA-259.
Reported-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reported-by: Andrew Cooper <andrew.cooper3@citrix.com>
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
--- a/xen/arch/x86/x86_64/entry.S
+++ b/xen/arch/x86/x86_64/entry.S
@@ -442,6 +442,12 @@ int80_slow_path:
movl $TRAP_gp_fault,UREGS_entry_vector(%rsp)
/* A GPF wouldn't have incremented the instruction pointer. */
subq $2,UREGS_rip(%rsp)
+ /*
+ * While we've cleared xen_cr3 above already, normal exception handling
+ * code has logic to restore the original value from %r15. Therefore we
+ * need to set up %r14 here, while %r15 is required to still be zero.
+ */
+ GET_STACK_BASE(%r14)
jmp handle_exception_saved
/* CREATE A BASIC EXCEPTION FRAME ON GUEST OS STACK: */
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic