* Xen Security Advisory 238 - DMOP map/unmap missing argument checks
@ 2017-10-12 12:16 Xen.org security team
0 siblings, 0 replies; only message in thread
From: Xen.org security team @ 2017-10-12 12:16 UTC (permalink / raw)
To: xen-announce, xen-devel, xen-users, oss-security; +Cc: Xen.org security team
[-- Attachment #1: Type: text/plain, Size: 3758 bytes --]
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Xen Security Advisory XSA-238
version 2
DMOP map/unmap missing argument checks
UPDATES IN VERSION 2
====================
Public release.
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*
3cced09a1fb2936644d654c568f38580952328b84e28601b019ea74122228c36 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
iQEcBAEBCAAGBQJZ31v7AAoJEIP+FMlX6CvZrBgIAMg3C1Gvc3rnrPjT+0Im7gdQ
vBXGAWViWDs7EC1Vl5IU6lQQKETNmx40kRPyOYOVSdPzWamOotXOSadpJ49mbTX1
CA2iSJ8OAdqcPhgKjdUYVJXkybujNp6WkdlcT6ZXvEs6DLuvKJXZBaRoX2vYtObq
JjwUfGgpHcOc8vLhaEjEZTWRnKJotqQPaPaDHzrtGJAkHB0F+gwqpM4lBD6Q18+/
DzyBWlDENEcoSwzDldZ/4Ktl/rOXDOPoYYZfnFmYA2puWP7ujonio8iofOy+6GH3
GoKSPs1ciC4ax1WdJqbuxM0TCStz4QFOselVQ0hEJNdH6k3mmA4wMg+6kPNDf2U=
=9idj
-----END PGP SIGNATURE-----
[-- Attachment #2: xsa238.meta --]
[-- Type: application/octet-stream, Size: 1867 bytes --]
{
"XSA": 238,
"SupportedVersions": [
"master",
"4.9",
"4.8",
"4.7",
"4.6",
"4.5"
],
"Trees": [
"xen"
],
"Recipes": {
"4.5": {
"XenVersion": "4.5",
"Recipes": {
"xen": {
"StableRef": "83724d9f3ae21a3b96362742e2f052b19d9f559a",
"Prereqs": [
237
],
"Patches": [
"xsa238-4.5.patch"
]
}
}
},
"4.6": {
"XenVersion": "4.6",
"Recipes": {
"xen": {
"StableRef": "1658a87690ac839e85db12bbf409be62bb938640",
"Prereqs": [
237
],
"Patches": [
"xsa238-4.6.patch"
]
}
}
},
"4.7": {
"XenVersion": "4.7",
"Recipes": {
"xen": {
"StableRef": "c7783d9c26fc191862d9883da22387340b1fab18",
"Prereqs": [
237
],
"Patches": [
"xsa238.patch"
]
}
}
},
"4.8": {
"XenVersion": "4.8",
"Recipes": {
"xen": {
"StableRef": "36898eb12572f0a1f85cb54d4a9e90afcb6f7045",
"Prereqs": [
237
],
"Patches": [
"xsa238.patch"
]
}
}
},
"4.9": {
"XenVersion": "4.9",
"Recipes": {
"xen": {
"StableRef": "2cc3d32f40c71cb242477a3f8938074d4fc36829",
"Prereqs": [
237
],
"Patches": [
"xsa238.patch"
]
}
}
},
"master": {
"XenVersion": "master",
"Recipes": {
"xen": {
"StableRef": "a8ea6e2688118a3e19e29b39e316faa5f96ab9d1",
"Prereqs": [
237
],
"Patches": [
"xsa238.patch"
]
}
}
}
}
}
[-- Attachment #3: xsa238.patch --]
[-- Type: application/octet-stream, Size: 1545 bytes --]
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;
[-- Attachment #4: xsa238-4.5.patch --]
[-- Type: application/octet-stream, Size: 1435 bytes --]
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;
[-- Attachment #5: xsa238-4.6.patch --]
[-- Type: application/octet-stream, Size: 1435 bytes --]
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 #6: Type: text/plain, Size: 127 bytes --]
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
^ permalink raw reply related [flat|nested] only message in thread
only message in thread, other threads:[~2017-10-12 12:16 UTC | newest]
Thread overview: (only message) (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2017-10-12 12:16 Xen Security Advisory 238 - DMOP map/unmap missing argument checks Xen.org security team
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).