Roundup: [oss-security] Xen Security Advisory 210 - arm: memory corruption when freeing p2m pages

[grahamc]

Here is a vulnerability from the oss-security mailing list
for Vulnerability Roundup 26.

Instructions:

Identification

Identify if we have the software, in 16.09, 17.03, and unstable.
Then determine if we are vulnerable, and make a comment with
your findings. It can also be helpful to specify if you think there is
a patch, or if it can be fixed via a general update.

Example:

unstable: we are not vulnerable (link to the package)
17.03: we are vulnerable (link to the package)
16.09: we don't have it packaged

IMPORTANT: If you believe there are possibly related issues, bring
them up on the parent issue!

Patching

Start by commenting on this issue saying you're working on a patch.
This way, we don't duplicate work.

If you open a pull request, tag this issue and the master issue
for the roundup.

If you commit the patch directly to a branch, please leave a comment
on this issue with the branch and the commit hash, example:

fixed:

release-16.09: abc123

Upon Completion ...

• Update Graham's database

Info

Triage Indicator:

-needs-triage +roundup26 thread:0000000000003de1 # [oss-security] Xen Security Advisory 210 - arm: memory corruption when freeing p2m pages

• File Search: https://search.nix.gsc.io/?q=xen&i=fosho&repos=nixos-nixpkgs
• GitHub Search: https://github.com/NixOS/nixpkgs/search?utf8=%E2%9C%93&q=xen+in%3Apath&type=Code

---

Thu, 23 Feb 2017 16:28:18 +0000 Xen.org security team <security-at-xen.org>, E1cgwFe-0005Mf-Pk@xenbits.xenproject.org

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

                    Xen Security Advisory XSA-210

             arm: memory corruption when freeing p2m pages

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

When freeing pages used for stage-2 page tables, the freeing routine
failed to remove these pages from an internally managed list they were
put on during allocation.  The same list node elements are also
used by the hypervisor's page allocator.  Subsequent manipulation of
ARM's private P2M list could therefore corrupt the lists maintained by
the page allocator.  The buggy code is exposed to guests via the
XENMEM_decrease_reservation hypercall.

IMPACT
======

A malicious or buggy guest may corrupt hypervisor state, commonly
leading to a host crash (Denial of Service).  Privilege escalation or
information leaks cannot be excluded.

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

Only Xen version 4.8 is affected.  Xen versions 4.7 and earlier are not
vulnerable.

Only ARM systems are vulnerable.  X86 based systems are not vulnerable.

MITIGATION
==========

There is no known mitigation.

NOTE REGARDING LACK OF EMBARGO
==============================

The issue was discussed publicly before being recognized as a security
issue.

RESOLUTION
==========

Applying the attached patch resolves this issue.

xsa210.patch           xen-unstable, Xen 4.8.x

$ sha256sum xsa210*
10e26c017c916dcac261c6a3c92656831f0ad037f792940e6faf6905c6e23861  xsa210.patch
$

CREDITS
=======

The initial bug was discovered by Vijay Kilari of Cavium and the
security aspect was diagnosed by Julien Grall of ARM.

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

iQEcBAEBAgAGBQJYrw2aAAoJEIP+FMlX6CvZuw4H/34z2io/65h2RLDL3bx4w//A
nWNcrceKrxyvtZmTss56RHrUeiOOKOeuCXWMx5CSihBcSRXqyZa79IDul9t1b7fB
m6NUPerILGueF3uOYTRUvvSiWKWRzVPOCgqSxlCmd7YTrkjHZkq/x2Gb9Acj3hrl
yE0fFdD/hTIN9wZtHWY+gTIXMIGHBJ4/xieZeYZvylbnmu9nDC0WIupTExonWqie
sG0DICl+eKJMt3ioSzaGd9117Xk1P7JWvcr7MJQvzn/2VDTG2TjC4kZE1iDHHVPz
+txQh2G2Luf+jX5VQSqWnlv7I9zuGlqYEpAMQacjrLzGejuqPSC2kbzliOEoCaE=
=1k3w
-----END PGP SIGNATURE-----

xsa210.patch

From: Julien Grall <julien.grall@arm.com>
Subject: arm/p2m: remove the page from p2m->pages list before freeing it

The p2m code is using the page list field to link all the pages used
for the stage-2 page tables. The page is added into the p2m->pages
list just after the allocation but never removed from the list.

The page list field is also used by the allocator, not removing may
result a later Xen crash due to inconsistency (see [1]).

This bug was introduced by the reworking of p2m code in commit 2ef3e36ec7
"xen/arm: p2m: Introduce p2m_set_entry and __p2m_set_entry".

[1] https://lists.xenproject.org/archives/html/xen-devel/2017-02/msg00524.html

Reported-by: Vijaya Kumar K <Vijaya.Kumar@cavium.com>
Signed-off-by: Julien Grall <julien.grall@arm.com>
Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>

--- a/xen/arch/arm/p2m.c
+++ b/xen/arch/arm/p2m.c
@@ -660,6 +660,7 @@ static void p2m_free_entry(struct p2m_domain *p2m,
     unsigned int i;
     lpae_t *table;
     mfn_t mfn;
+    struct page_info *pg;
 
     /* Nothing to do if the entry is invalid. */
     if ( !p2m_valid(entry) )
@@ -697,7 +698,10 @@ static void p2m_free_entry(struct p2m_domain *p2m,
     mfn = _mfn(entry.p2m.base);
     ASSERT(mfn_valid(mfn_x(mfn)));
 
-    free_domheap_page(mfn_to_page(mfn_x(mfn)));
+    pg = mfn_to_page(mfn_x(mfn));
+
+    page_list_del(pg, &p2m->pages);
+    free_domheap_page(pg);
 }
 
 static bool p2m_split_superpage(struct p2m_domain *p2m, lpae_t *entry,

---

[Mic92]

Well is Xen on Nixos on ARM (not aarch64) really a thing?

[Mic92]

If somebody process this list of, we should be good to go: https://xenbits.xen.org/xsa/
All patches come from upstream. Not all seems to be yet applied in our version of Xen.

[grahamc]

I have no idea about Xen on NixOS on ARM :P 4.5 is still supported, but running out I think. I'm hoping @oxij will upgrade us someday :) We should have almost all the Xen patches already, up to 209.

[Mic92]

I saw several older patches missing.

[grahamc]

210 doesn't apply to 4.5.