xen-devel.lists.xenproject.org archive mirror
 help / color / mirror / Atom feed
* Xen Security Advisory 31 (CVE-2012-5515) - Several memory hypercall operations allow invalid extent order values
@ 2012-12-03 17:51 Xen.org security team
  0 siblings, 0 replies; only message in thread
From: Xen.org security team @ 2012-12-03 17:51 UTC (permalink / raw)
  To: xen-announce, xen-devel, xen-users, oss-security; +Cc: Xen.org security team

[-- 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

^ permalink raw reply related	[flat|nested] only message in thread

only message in thread, other threads:[~2012-12-03 17:51 UTC | newest]

Thread overview: (only message) (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2012-12-03 17:51 Xen Security Advisory 31 (CVE-2012-5515) - Several memory hypercall operations allow invalid extent order values 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).