[prev in list] [next in list] [prev in thread] [next in thread] 

List:       oss-security
Subject:    [oss-security] Xen Security Advisory 74 (CVE-2013-4553) - Lock order reversal between page_alloc_loc
From:       Xen.org security team <security () xen ! org>
Date:       2013-11-26 17:03:23
Message-ID: E1VlM2l-0002YF-0k () xenbits ! xen ! org
[Download RAW message or body]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

             Xen Security Advisory CVE-2013-4553 / XSA-74
                              version 3

          Lock order reversal between page_alloc_lock and mm_rwlock

UPDATES IN VERSION 3
====================

Public release.

ISSUE DESCRIPTION
=================

The locks page_alloc_lock and mm_rwlock are not always taken in
the same order.  This raises the possibility of deadlock.

The incorrect order occurs only in the implementation of the
deprecated domctl hypercall XEN_DOMCTL_getmemlist.

IMPACT
======

A malicious guest administrator may be able to deny service to the
entire host.

VULNERABLE SYSTEMS
==================

Xen 3.4.x and later are vulnerable.
Xen 3.3.x and earlier are not vulnerable.

Only systems where a privileged domain frequently or predictably uses
XEN_DOMCTL_getmemlist are vulnerable.  (Its use by manually invoked
debugging and stress testing tools is not a security problem.)

We are not aware of any toolstack software which has relevant (and
hence vulnerable) uses of this hypercall.  xend, libxl, xapi and
libvirt are known not to do so.

We are therefore not aware of any deployed Xen-based systems which are
vulnerable.  We are issuing this advisory primarily for the benefit of
any Xen-derived systems using unusual toolstack software.

MITIGATION
==========

If you are using a toolstack (or other software) which uses
XEN_DOMCTL_getmemlist, disabling the relevant feature or functions may
be possible, and would avoid the vulnerability.

CREDITS
=======

This issue was discovered by Coverity Scan and diagnosed by Andrew
Cooper.

RESOLUTION
==========

Applying the appropriate attached patch resolves this issue.

xsa74-4.3-unstable.patch    Xen 4.3.x, xen-unstable
xsa74-4.1-4.2.patch         Xen 4.1.x, Xen 4.2.x

$ sha256sum xsa74*.patch
0f7d0bbfbd7f3f1b6f6005321fa45081524dad438587f691e6892cc393327f89  xsa74-4.1-4.2.patch
b505cdba662b1b1cd91d5611fac998c6b4e89e366780c6b9864b6965075afb38  xsa74-4.3-unstable.patch
$
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)

iQEbBAEBAgAGBQJSlNQrAAoJEIP+FMlX6CvZ0mQH91vaeR1HM9utM5SJqnVMVp9T
lUsZRRsrI95Dh7dDaNl9IJC0vCWlIbdA4zMaSblYQtTkS8d6zx6psi9udjgkHGPj
ZzKuJHN+qccXzphGe/pyIoA/Lpxk4at/JmNXzbXBonf1IOs6S9rVRkofyNswSWZC
2y8rKSrhXDMqrRKw42VEVWnmhiY8oV9Bez/+N0fEL1rhH8TxJYiQVGTlryquR6ye
1kvBsVYRQtYzjAWqj51wjFdeJnK9/l1W1jYDgPEZbe4fWUlhF1IlRLJVm+e9VpJd
CdWGG4oBpVcXGig0mYFJ3Bmw5gmOi9zseXEDXbo7b0Xfw1tOIGujaHKN6eFj7A==
=B5QR
-----END PGP SIGNATURE-----

["xsa74-4.1-4.2.patch" (application/octet-stream)]

x86: restrict XEN_DOMCTL_getmemlist

Coverity ID 1055652

(See the code comment.)

This is CVE-2013-4553 / XSA-74.

Signed-off-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Tim Deegan <tim@xen.org>

--- a/xen/arch/x86/domctl.c
+++ b/xen/arch/x86/domctl.c
@@ -385,6 +385,26 @@ long arch_do_domctl(
                 break;
             }
 
+            /*
+             * XSA-74: This sub-hypercall is broken in several ways:
+             * - lock order inversion (p2m locks inside page_alloc_lock)
+             * - no preemption on huge max_pfns input
+             * - not (re-)checking d->is_dying with page_alloc_lock held
+             * - not honoring start_pfn input (which libxc also doesn't set)
+             * Additionally it is rather useless, as the result is stale by
+             * the time the caller gets to look at it.
+             * As it only has a single, non-production consumer (xen-mceinj),
+             * rather than trying to fix it we restrict it for the time being.
+             */
+            if ( /* No nested locks inside copy_to_guest_offset(). */
+                 paging_mode_external(current->domain) ||
+                 /* Arbitrary limit capping processing time. */
+                 max_pfns > GB(4) / PAGE_SIZE )
+            {
+                ret = -EOPNOTSUPP;
+                break;
+            }
+
             spin_lock(&d->page_alloc_lock);
 
             if ( unlikely(d->is_dying) ) {

["xsa74-4.3-unstable.patch" (application/octet-stream)]

x86: restrict XEN_DOMCTL_getmemlist

Coverity ID 1055652

(See the code comment.)

This is CVE-2013-4553 / XSA-74.

Signed-off-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Tim Deegan <tim@xen.org>

--- a/xen/arch/x86/domctl.c
+++ b/xen/arch/x86/domctl.c
@@ -329,6 +329,26 @@ long arch_do_domctl(
             break;
         }
 
+        /*
+         * XSA-74: This sub-hypercall is broken in several ways:
+         * - lock order inversion (p2m locks inside page_alloc_lock)
+         * - no preemption on huge max_pfns input
+         * - not (re-)checking d->is_dying with page_alloc_lock held
+         * - not honoring start_pfn input (which libxc also doesn't set)
+         * Additionally it is rather useless, as the result is stale by the
+         * time the caller gets to look at it.
+         * As it only has a single, non-production consumer (xen-mceinj),
+         * rather than trying to fix it we restrict it for the time being.
+         */
+        if ( /* No nested locks inside copy_to_guest_offset(). */
+             paging_mode_external(current->domain) ||
+             /* Arbitrary limit capping processing time. */
+             max_pfns > GB(4) / PAGE_SIZE )
+        {
+            ret = -EOPNOTSUPP;
+            break;
+        }
+
         spin_lock(&d->page_alloc_lock);
 
         ret = i = 0;


[prev in list] [next in list] [prev in thread] [next in thread]