Xen Security Advisory 284 v2 - grant table transfer issues on large hosts

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

                    Xen Security Advisory XSA-284
                              version 2

              grant table transfer issues on large hosts

UPDATES IN VERSION 2
====================

Metadata updated to remove dependency on XSA-283.

Public release.

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

When the code processing grant table transfer requests finds a page with
an address too large to be represented in the interface with the guest,
it allocates a replacement page and copies page contents.  However, the
code doing so fails to set the newly allocated page's accounting
properties correctly, resulting in the page becoming not only unusable
by the target domain, but also unfreeable upon domain cleanup.  The page
as well as certain other remnants of an affected guest will be leaked.

Furthermore internal state of the processing code was also not updated
correctly, resulting in the insertion of an IOMMU mapping to the page
being replaced (and subsequently freed), allowing the domain access to
memory it does not own.

IMPACT
======

The primary impact is a memory leak.  Malicious or buggy guests with
passed through PCI devices may also be able to escalate their
privileges, crash the host, or access data belonging to other guests.

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

All Xen versions from at least 3.2 onwards are vulnerable.

64-bit x86 PV guests can leverage the vulnerability on hosts with
physical memory extending past the 16 TiB boundary.  This is only
possible for hypervisors built with CONFIG_BIGMEM enabled.

32-bit x86 PV guests can leverage the vulnerability on hosts with
physical memory extending past the 168 GiB boundary.

x86 HVM and PVH guests cannot leverage the vulnerability on libxl
based systems.  On xend based systems x86 HVM guests can leverage
the vulnerability if their guest config file has a
'machine_address_size' setting.

ARM systems are not vulnerable.

MITIGATION
==========

Running only x86 HVM/PVH guests will avoid this vulnerability.

CREDITS
=======

This issue was discovered by Jan Beulich of SUSE.

RESOLUTION
==========

Applying the attached patch resolves this issue.

xsa284.patch           xen-unstable, Xen 4.11.x ... 4.7.x

$ sha256sum xsa284*
5359796890fc59dd2bbf8d23398c229153c8b9b716c01842dfb9f95d063a3ad4  xsa284.meta
3a95ae9faef3886fd3a4ed5b22d944939bb2f819bb5a2a8061b2311cf3c05776  xsa284.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-----

iQFABAEBCAAqFiEEI+MiLBRfRHX6gGCng/4UyVfoK9kFAlx+aa0MHHBncEB4ZW4u
b3JnAAoJEIP+FMlX6CvZwsYH/1yPmIG8vO86sWbX4bvwOsiRQMyy+U/HGKnh3kRi
lkDap3srzCRNveh/pqIJQF0okH/gD5VfHZrr3D73cHK7JKmlhoI0bPhpb6oE7/10
SmnaL/cW6/75FuDGdWzmKqx56Y/Ho/wxqGBj69rBbleOnGv+RHUQuGGTZ9g4rmzb
Nn4DbVRLz2cqvQhHmwjQBl/unid1BAnHVATHnNdjlF/SgucR7oRweioYjTeoFbZv
AdAWXX1GJRoXokGd1uE0eo/Mice/zmlHp//5JADCzo/oPevBFixMw/KWCaCMmUJt
FyDNwlu8xtm/bopBWN9dGc2tSKj/0UnTA7FF61OG39BdJHo=
=EzAi
-----END PGP SIGNATURE-----

_______________________________________________
Xen-announce mailing list
[email protected]
https://lists.xenproject.org/mailman/listinfo/xen-announce

From: Jan Beulich <[email protected]>
Subject: gnttab: set page refcount for copy-on-grant-transfer

Commit 5cc77f9098 ("32-on-64: Fix domain address-size clamping,
implement"), which introduced this functionality, took care of clearing
the old page's PGC_allocated, but failed to set the bit (and install the
associated reference) on the newly allocated one. Furthermore the "mfn"
local variable was never updated, and hence the wrong MFN was passed to
guest_physmap_add_page() (and back to the destination domain) in this
case, leading to an IOMMU mapping into an unowned page.

Ideally the code would use assign_pages(), but the call to
gnttab_prepare_for_transfer() sits in the middle of the actions
mirroring that function.

This is XSA-284.

Signed-off-by: Jan Beulich <[email protected]>
Acked-by: George Dunlap <[email protected]>

--- a/xen/common/grant_table.c
+++ b/xen/common/grant_table.c
@@ -2183,6 +2183,8 @@ gnttab_transfer(
             page->count_info &= ~(PGC_count_mask|PGC_allocated);
             free_domheap_page(page);
             page = new_page;
+            page->count_info = PGC_allocated | 1;
+            mfn = page_to_mfn(page);
         }
 
         spin_lock(&e->page_alloc_lock);