xen-devel.lists.xenproject.org archive mirror
 help / color / mirror / Atom feed
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).