From: Xen.org security team <security@xen.org>
To: xen-announce@lists.xen.org, xen-devel@lists.xen.org,
xen-users@lists.xen.org, oss-security@lists.openwall.com
Cc: "Xen.org security team" <security@xen.org>
Subject: Xen Security Advisory 31 (CVE-2012-5515) - Several memory hypercall operations allow invalid extent order values
Date: Mon, 03 Dec 2012 17:51:47 +0000 [thread overview]
Message-ID: <E1TfaBH-00068a-7n@xenbits.xen.org> (raw)
[-- Attachment #1: Type: text/plain, Size: 1850 bytes --]
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Xen Security Advisory CVE-2012-5515 / XSA-31
version 3
Several memory hypercall operations allow invalid extent order values
UPDATES IN VERSION 3
====================
Public release.
ISSUE DESCRIPTION
=================
Allowing arbitrary extent_order input values for XENMEM_decrease_reservation,
XENMEM_populate_physmap, and XENMEM_exchange can cause arbitrarily long time
being spent in loops without allowing vital other code to get a chance to
execute. This may also cause inconsistent state resulting at the completion
of these hypercalls.
IMPACT
======
A malicious guest administrator can cause Xen to hang.
VULNERABLE SYSTEMS
==================
All Xen versions are vulnerable. However, older versions (not supporting
Populate-on-Demand, i.e. before 3.4) may only be theoretically affected.
MITIGATION
==========
Running only trusted guest kernels will avoid this vulnerability.
RESOLUTION
==========
Applying the appropriate attached patch resolves this issue.
xsa31-4.1.patch Xen 4.1.x
xsa31-4.2-unstable.patch Xen 4.2.x, xen-unstable
$ sha256sum xsa31*.patch
8e4bb43999d1a72d7f1b6ad3e66d0c173ca711c8145c5804b025eaa63d2c1691 xsa31-4.1.patch
090d0cca3eddaee798e5f06a8d5f469d47f874c657abcd6028248d949d36da81 xsa31-4.2-unstable.patch
$
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
iQEcBAEBAgAGBQJQvOJ4AAoJEIP+FMlX6CvZhCgIAIAkB8EpoFU0vwCW26toELFh
3odZ8kji4hBoIaR6vOj4BIrSuTxC+0TZl3JGSwxQ+zo2k15njNqPZM/8m5kztLzZ
K79GXhSRb6zo96EmAhxX6wU4qpBdDH7htdAsO74ApHdfw3hw9yXY2h+OkwiYTO6J
K0TegvNYoJ+9NJ4ePTgZpHp4B1H4ymtvw84uzNBJQ6ePR95lV4aOq7h1loIvMPzB
Mcxy+3LTAZasK7yYZLClyHXR46pN41qbMawKYNMp70+fQvyP58P6cExwZ4ODrbHf
dfgEg2yNeI4YXzOx2vbRSDRDAzf4lhGHq9fXhUpNF/denRJJCC9r/E0+nWTzWog=
=CUvM
-----END PGP SIGNATURE-----
[-- Attachment #2: xsa31-4.1.patch --]
[-- Type: application/octet-stream, Size: 2121 bytes --]
memop: limit guest specified extent order
Allowing unbounded order values here causes almost unbounded loops
and/or partially incomplete requests, particularly in PoD code.
The added range checks in populate_physmap(), decrease_reservation(),
and the "in" one in memory_exchange() architecturally all could use
PADDR_BITS - PAGE_SHIFT, and are being artificially constrained to
MAX_ORDER.
This is XSA-31 / CVE-2012-5515.
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Tim Deegan <tim@xen.org>
Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
diff --git a/xen/common/memory.c b/xen/common/memory.c
index 4e7c234..9b9fb18 100644
--- a/xen/common/memory.c
+++ b/xen/common/memory.c
@@ -117,7 +117,8 @@ static void populate_physmap(struct memop_args *a)
if ( a->memflags & MEMF_populate_on_demand )
{
- if ( guest_physmap_mark_populate_on_demand(d, gpfn,
+ if ( a->extent_order > MAX_ORDER ||
+ guest_physmap_mark_populate_on_demand(d, gpfn,
a->extent_order) < 0 )
goto out;
}
@@ -216,7 +217,8 @@ static void decrease_reservation(struct memop_args *a)
xen_pfn_t gmfn;
if ( !guest_handle_subrange_okay(a->extent_list, a->nr_done,
- a->nr_extents-1) )
+ a->nr_extents-1) ||
+ a->extent_order > MAX_ORDER )
return;
for ( i = a->nr_done; i < a->nr_extents; i++ )
@@ -278,6 +280,9 @@ static long memory_exchange(XEN_GUEST_HANDLE(xen_memory_exchange_t) arg)
if ( (exch.nr_exchanged > exch.in.nr_extents) ||
/* Input and output domain identifiers match? */
(exch.in.domid != exch.out.domid) ||
+ /* Extent orders are sensible? */
+ (exch.in.extent_order > MAX_ORDER) ||
+ (exch.out.extent_order > MAX_ORDER) ||
/* Sizes of input and output lists do not overflow a long? */
((~0UL >> exch.in.extent_order) < exch.in.nr_extents) ||
((~0UL >> exch.out.extent_order) < exch.out.nr_extents) ||
[-- Attachment #3: xsa31-4.2-unstable.patch --]
[-- Type: application/octet-stream, Size: 2127 bytes --]
memop: limit guest specified extent order
Allowing unbounded order values here causes almost unbounded loops
and/or partially incomplete requests, particularly in PoD code.
The added range checks in populate_physmap(), decrease_reservation(),
and the "in" one in memory_exchange() architecturally all could use
PADDR_BITS - PAGE_SHIFT, and are being artificially constrained to
MAX_ORDER.
This is XSA-31 / CVE-2012-5515.
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Tim Deegan <tim@xen.org>
Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
diff --git a/xen/common/memory.c b/xen/common/memory.c
index 83e2666..2e56d46 100644
--- a/xen/common/memory.c
+++ b/xen/common/memory.c
@@ -115,7 +115,8 @@ static void populate_physmap(struct memop_args *a)
if ( a->memflags & MEMF_populate_on_demand )
{
- if ( guest_physmap_mark_populate_on_demand(d, gpfn,
+ if ( a->extent_order > MAX_ORDER ||
+ guest_physmap_mark_populate_on_demand(d, gpfn,
a->extent_order) < 0 )
goto out;
}
@@ -235,7 +236,8 @@ static void decrease_reservation(struct memop_args *a)
xen_pfn_t gmfn;
if ( !guest_handle_subrange_okay(a->extent_list, a->nr_done,
- a->nr_extents-1) )
+ a->nr_extents-1) ||
+ a->extent_order > MAX_ORDER )
return;
for ( i = a->nr_done; i < a->nr_extents; i++ )
@@ -297,6 +299,9 @@ static long memory_exchange(XEN_GUEST_HANDLE_PARAM(xen_memory_exchange_t) arg)
if ( (exch.nr_exchanged > exch.in.nr_extents) ||
/* Input and output domain identifiers match? */
(exch.in.domid != exch.out.domid) ||
+ /* Extent orders are sensible? */
+ (exch.in.extent_order > MAX_ORDER) ||
+ (exch.out.extent_order > MAX_ORDER) ||
/* Sizes of input and output lists do not overflow a long? */
((~0UL >> exch.in.extent_order) < exch.in.nr_extents) ||
((~0UL >> exch.out.extent_order) < exch.out.nr_extents) ||
[-- Attachment #4: Type: text/plain, Size: 126 bytes --]
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
reply other threads:[~2012-12-03 17:51 UTC|newest]
Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=E1TfaBH-00068a-7n@xenbits.xen.org \
--to=security@xen.org \
--cc=oss-security@lists.openwall.com \
--cc=xen-announce@lists.xen.org \
--cc=xen-devel@lists.xen.org \
--cc=xen-users@lists.xen.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
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).