Xen Security Advisory 147 (CVE-2015-7814) - arm: Race between domain destruction and memory allocation decrease

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

            Xen Security Advisory CVE-2015-7814 / XSA-147
                              version 3

 arm: Race between domain destruction and memory allocation decrease

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

Public release.

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

While freeing the memory associated with a domain during domain
destruction Xen could race with a toolstack domain reducing the
amount of memory associated with that same domain via the
XENMEM_decrease_reservation.

In the case where this race is hit the host will crash.

The race is not exposed via the XENMEM_remove_from_physmap or
XENMEM_exchange interfaces.

IMPACT
======

Domains deliberately given partial management control may be able to
deny service by crashing the host.

Such a domain needs to be granted access to at least one of
XENMEM_decrease_reservation or XEN_DOMCTL_destroydomain over another
domain.

As a result, in a system designed to enhance security by radically
disaggregating the management, the security may be reduced.  But, the
security will be no worse than a non-disaggregated design.

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

This issue is only relevant to systems which intend to increase
security through the use of advanced disaggregated management
techniques.

This does not include systems using libxl, libvirt, or OpenStack
(unless substantially modified or supplemented, as compared to
versions supplied by the respective upstreams).

Only ARM systems are potentially affected.  All Xen versions which
support ARM are potentially affected.

x86 systems are not affected.

MITIGATION
==========

There is no known mitigation.

Switching from disaggregated to a non-disaggregated operation does NOT
mitigate these vulnerabilities.  Rather, it simply recategorises the
vulnerability to hostile management code, regarding it "as designed";
thus it merely reclassifies these issues as "not a bug".  Users and
vendors of disaggregated systems should not change their
configuration.

CREDITS
=======

This issue was discovered by Ian Campbell of Citrix.

RESOLUTION
==========

Applying the attached patch resolves this issue.

xsa147.patch        xen-unstable, Xen 4.6.x, Xen 4.5.x, Xen 4.4.x

$ sha256sum xsa147*.patch
35cd9c5dabd5af6756957cf7378d527b2fcbff35dcf578769769a364a98ea6ac  xsa147.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.4.12 (GNU/Linux)

iQEcBAEBAgAGBQJWMgm3AAoJEIP+FMlX6CvZHPAIAIgXu4741IJeO/Pb187gxO3Z
IXpSSJF1Fvof/Ma6LLSGRth94WiafF91MKKqlEAKFPyfRUOkJXHAoahDUe7lF1Lr
V5qSA4jAu69ZIhg3AAKuI+xBV/PNx7rlaG0duRI9nHmLRhbIU3EF9YJbKntdZzZr
gdE/zLk+moW4U2/quEIEQGqtDGr/RAm5N0MqGwW4mcHUhlp4XcNuqrC8+b5qaeJ3
8/pc9whzyHM04De5Ve9/iFUu0J6KxNK+hN9V14mO8bcPXzK/K8X4C3qUD6HtZx+U
VsaKT/N4INNDg7wqULcjg/Vp23SE/mUPM8Fernee9KnI2CY3pnS9DB1KEYMry5s=
=7g7l
-----END PGP SIGNATURE-----

_______________________________________________
Xen-announce mailing list
[email protected]
http://lists.xen.org/xen-announce

xen: arm: handle races between relinquish_memory and free_domheap_pages

Primarily this means XENMEM_decrease_reservation from a toolstack
domain.

Unlike x86 we have no requirement right now to queue such pages onto
a separate list, if we hit this race then the other code has already
fully accepted responsibility for freeing this page and therefore
there is no more for relinquish_memory to do.

This is XSA-147.

Signed-off-by: Ian Campbell <[email protected]>
Reviewed-by: Julien Grall <[email protected]>
Reviewed-by: Jan Beulich <[email protected]>

diff --git a/xen/arch/arm/domain.c b/xen/arch/arm/domain.c
index 575745c..aac64cb 100644
--- a/xen/arch/arm/domain.c
+++ b/xen/arch/arm/domain.c
@@ -764,8 +764,15 @@ static int relinquish_memory(struct domain *d, struct page_list_head *list)
     {
         /* Grab a reference to the page so it won't disappear from under us. */
         if ( unlikely(!get_page(page, d)) )
-            /* Couldn't get a reference -- someone is freeing this page. */
-            BUG();
+            /*
+             * Couldn't get a reference -- someone is freeing this page and
+             * has already committed to doing so, so no more to do here.
+             *
+             * Note that the page must be left on the list, a list_del
+             * here will clash with the list_del done by the other
+             * party in the race and corrupt the list head.
+             */
+            continue;
 
         if ( test_and_clear_bit(_PGC_allocated, &page->count_info) )
             put_page(page);