[prev in list] [next in list] [prev in thread] [next in thread]
List: xen-announce
Subject: [Xen-announce] Xen Security Advisory 238 (CVE-2017-15591) - DMOP map/unmap missing argument checks
From: Xen.org security team <security () xen ! org>
Date: 2017-12-06 10:59:42
Message-ID: E1eMXQU-0001T7-NM () xenbits ! xenproject ! org
[Download RAW message or body]
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Xen Security Advisory CVE-2017-15591 / XSA-238
version 3
DMOP map/unmap missing argument checks
UPDATES IN VERSION 3
====================
CVE assigned.
ISSUE DESCRIPTION
=================
DMOPs (which were a subgroup of HVMOPs in older releases) allow guests
to control and drive other guests. The I/O request server page mapping
interface uses range sets to represent I/O resources the emulation of
which is provided by a given I/O request server. The internals of the
range set implementation require that ranges have a starting value no
lower than the ending one. Checks for this fact were missing.
IMPACT
======
Malicious or buggy stub domain kernels or tool stacks otherwise living
outside of Domain0 can mount a denial of service attack which, if
successful, can affect the whole system.
Only domains controlling HVM guests can exploit this vulnerability.
(This includes domains providing hardware emulation services to HVM
guests.)
VULNERABLE SYSTEMS
==================
Xen versions 4.5 and later are vulnerable. Xen versions 4.4 and
earlier are not vulnerable.
Only x86 systems are affected. ARM systems are not affected.
This vulnerability is only applicable to Xen systems using stub domains
or other forms of disaggregation of control domains for HVM guests.
MITIGATION
==========
Running only PV guests will avoid this issue.
(The security of a Xen system using stub domains is still better than
with a qemu-dm running as an unrestricted dom0 process. Therefore
users with these configurations should not switch to an unrestricted
dom0 qemu-dm.)
CREDITS
=======
This issue was discovered by Vitaly Kuznetsov of RedHat.
RESOLUTION
==========
Applying the appropriate attached patch resolves this issue.
xsa238.patch xen-unstable, Xen 4.9.x, Xen 4.8.x, Xen 4.7.x
xsa238-4.6.patch Xen 4.6.x
xsa238-4.5.patch Xen 4.5.x
$ sha256sum xsa238*
93cc1da4a0ab27f857f2ad39c38f112ef101a01bc5d386807d27371f83526831 xsa238.meta
85d3f9713bef1bc86c682857dbd7388a1d1f20089363ddfc4cb9ecbd88eaffec xsa238.patch
034e91c234f6831dbaa1aaf29f4f90de2e822f99301424f7f3527f9da883ff68 xsa238-4.5.patch
29255a81729b24866e594426167de5fbef70de21ef62a95ba95de191d2a7fd54 xsa238-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
iQEcBAEBCAAGBQJaJ82OAAoJEIP+FMlX6CvZcU0IAMkUqTbbTWIWAruO03YSxFvn
bqmfyzgyUVHUMLzhjrukaqVxZYcxV5FbY/IMWEZY/oET9wHv8iBsMay+cVlsv45i
GMHZaxGBM9P1xU6AS4GP/oRMb9LA4fU7rjCKcK54zaDV+mdW/2rA+Ac0IVbmn3tF
gcnkfbHk3cF8x91rD4+2ZC7ihE6CIX70PQxdXNbgR8RpoxGdE1q9IPF8ik3gLyO/
OtoDfqrbau+YllhTBI3XxmU+MJgpRf+VRnOgFpYjzp10dfVBM459Lmdzfa6gXhxz
ysm+Js8Y4jpVEIGY3qXAV8/V2ZSL8nNmFiNFPOJZcNu4wkAFZKUlyWBbFlJcvvk=
=keh/
-----END PGP SIGNATURE-----
["xsa238.meta" (application/octet-stream)]
["xsa238.patch" (application/octet-stream)]
From cdc2887076b19b39fab9faec495082586f3113df Mon Sep 17 00:00:00 2001
From: XenProject Security Team <security@xenproject.org>
Date: Tue, 5 Sep 2017 13:41:37 +0200
Subject: x86/ioreq server: correctly handle bogus
XEN_DMOP_{,un}map_io_range_to_ioreq_server arguments
Misbehaving device model can pass incorrect XEN_DMOP_map/
unmap_io_range_to_ioreq_server arguments, namely end < start when
specifying address range. When this happens we hit ASSERT(s <= e) in
rangeset_contains_range()/rangeset_overlaps_range() with debug builds.
Production builds will not trap right away but may misbehave later
while handling such bogus ranges.
This is XSA-238.
Signed-off-by: Vitaly Kuznetsov <vkuznets@redhat.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
---
xen/arch/x86/hvm/ioreq.c | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/xen/arch/x86/hvm/ioreq.c b/xen/arch/x86/hvm/ioreq.c
index b2a8b0e986..8c8bf1f0ec 100644
--- a/xen/arch/x86/hvm/ioreq.c
+++ b/xen/arch/x86/hvm/ioreq.c
@@ -820,6 +820,9 @@ int hvm_map_io_range_to_ioreq_server(struct domain *d, ioservid_t id,
struct hvm_ioreq_server *s;
int rc;
+ if ( start > end )
+ return -EINVAL;
+
spin_lock_recursive(&d->arch.hvm_domain.ioreq_server.lock);
rc = -ENOENT;
@@ -872,6 +875,9 @@ int hvm_unmap_io_range_from_ioreq_server(struct domain *d, ioservid_t id,
struct hvm_ioreq_server *s;
int rc;
+ if ( start > end )
+ return -EINVAL;
+
spin_lock_recursive(&d->arch.hvm_domain.ioreq_server.lock);
rc = -ENOENT;
["xsa238-4.5.patch" (application/octet-stream)]
From: XenProject Security Team <security@xenproject.org>
Subject: x86/ioreq server: correctly handle bogus
XEN_DMOP_{,un}map_io_range_to_ioreq_server arguments
Misbehaving device model can pass incorrect XEN_DMOP_map/
unmap_io_range_to_ioreq_server arguments, namely end < start when
specifying address range. When this happens we hit ASSERT(s <= e) in
rangeset_contains_range()/rangeset_overlaps_range() with debug builds.
Production builds will not trap right away but may misbehave later
while handling such bogus ranges.
This is XSA-238.
Signed-off-by: Vitaly Kuznetsov <vkuznets@redhat.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
---
xen/arch/x86/hvm/hvm.c | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/xen/arch/x86/hvm/ioreq.c b/xen/arch/x86/hvm/ioreq.c
index b2a8b0e986..8c8bf1f0ec 100644
--- a/xen/arch/x86/hvm/hvm.c
+++ b/xen/arch/x86/hvm/hvm.c
@@ -1151,6 +1151,9 @@ int hvm_map_io_range_to_ioreq_server(struct domain *d, ioservid_t id,
struct hvm_ioreq_server *s;
int rc;
+ if ( start > end )
+ return -EINVAL;
+
spin_lock_recursive(&d->arch.hvm_domain.ioreq_server.lock);
rc = -ENOENT;
@@ -1202,6 +1205,9 @@ int hvm_unmap_io_range_from_ioreq_server(struct domain *d, ioservid_t id,
struct hvm_ioreq_server *s;
int rc;
+ if ( start > end )
+ return -EINVAL;
+
spin_lock_recursive(&d->arch.hvm_domain.ioreq_server.lock);
rc = -ENOENT;
["xsa238-4.6.patch" (application/octet-stream)]
From: XenProject Security Team <security@xenproject.org>
Subject: x86/ioreq server: correctly handle bogus
XEN_DMOP_{,un}map_io_range_to_ioreq_server arguments
Misbehaving device model can pass incorrect XEN_DMOP_map/
unmap_io_range_to_ioreq_server arguments, namely end < start when
specifying address range. When this happens we hit ASSERT(s <= e) in
rangeset_contains_range()/rangeset_overlaps_range() with debug builds.
Production builds will not trap right away but may misbehave later
while handling such bogus ranges.
This is XSA-238.
Signed-off-by: Vitaly Kuznetsov <vkuznets@redhat.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
---
xen/arch/x86/hvm/hvm.c | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/xen/arch/x86/hvm/ioreq.c b/xen/arch/x86/hvm/ioreq.c
index b2a8b0e986..8c8bf1f0ec 100644
--- a/xen/arch/x86/hvm/hvm.c
+++ b/xen/arch/x86/hvm/hvm.c
@@ -1271,6 +1271,9 @@ int hvm_map_io_range_to_ioreq_server(struct domain *d, ioservid_t id,
struct hvm_ioreq_server *s;
int rc;
+ if ( start > end )
+ return -EINVAL;
+
spin_lock_recursive(&d->arch.hvm_domain.ioreq_server.lock);
rc = -ENOENT;
@@ -1322,6 +1325,9 @@ int hvm_unmap_io_range_from_ioreq_server(struct domain *d, ioservid_t id,
struct hvm_ioreq_server *s;
int rc;
+ if ( start > end )
+ return -EINVAL;
+
spin_lock_recursive(&d->arch.hvm_domain.ioreq_server.lock);
rc = -ENOENT;
[Attachment #7 (text/plain)]
_______________________________________________
Xen-announce mailing list
Xen-announce@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-announce
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic