Information

AdvisoryXSA-384
Public release 2021-09-08 12:00
Updated 2021-09-08 12:27
Version 3
CVE(s) CVE-2021-28701
Title Another race in XENMAPSPACE_grant_table handling

Files

advisory-384.txt (signed advisory file)
xsa384.patch
xsa384-4.11.patch
xsa384-4.14.patch

Advisory


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

            Xen Security Advisory CVE-2021-28701 / XSA-384
                               version 3

            Another race in XENMAPSPACE_grant_table handling

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

Public release.

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

Guests are permitted access to certain Xen-owned pages of memory.  The
majority of such pages remain allocated / associated with a guest for
its entire lifetime.  Grant table v2 status pages, however, are
de-allocated when a guest switches (back) from v2 to v1.  Freeing
such pages requires that the hypervisor enforce that no parallel request
can result in the addition of a mapping of such a page to a guest.  That
enforcement was missing, allowing guests to retain access to pages
that were freed and perhaps re-used for other purposes.

Unfortunately, when XSA-379 was being prepared, this similar issue was
not noticed.

IMPACT
======

A malicious guest may be able to elevate its privileges to that of the
host, cause host or guest Denial of Service (DoS), or cause information
leaks.

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

All Xen versions from 4.0 onwards are affected.  Xen versions 3.4 and
older are not affected.

Only x86 HVM and PVH guests permitted to use grant table version 2
interfaces can leverage this vulnerability.  x86 PV guests cannot
leverage this vulnerability.  On Arm, grant table v2 use is explicitly
unsupported.

MITIGATION
==========

Running only PV guests will avoid this vulnerability.

Suppressing use of grant table v2 interfaces for HVM or PVH guests will
also avoid this vulnerability.

NOTE REGARDING EMBARGO
======================

Please note that the public embargo time for this advisory is
2021-09-08, two weeks later than XSA-378,379,380,382,383.

CREDITS
=======

This issue was discovered by Julien Grall of Amazon.

RESOLUTION
==========

Applying the appropriate attached patch resolves this issue.

Note that patches for released versions are generally prepared to
apply to the stable branches, and may not apply cleanly to the most
recent release tarball.  Downstreams are encouraged to update to the
tip of the stable branch before applying these patches.

xsa384.patch           xen-unstable - Xen 4.15.x
xsa384-4.14.patch      Xen 4.14.x - 4.12.x
xsa384-4.11.patch      Xen 4.11.x

$ sha256sum xsa384*
3bf555e8b2a37dec361b86c0b6a3f59af2e1a24e3457ed92e0cfeaa662f1663a  xsa384.patch
435b431dc77d255031832dc265a8d5aa2f13f3b1a7de497b62ac2df5ad61da90  xsa384-4.11.patch
f98ec4c25fb122de6353eb7d9f5678dd09982f887bf201d6f178e9b647618c9a  xsa384-4.14.patch
$

DEPLOYMENT DURING EMBARGO
=========================

Deployment of the patches and/or PV-guest-only 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.

HOWEVER, distribution of updated software is prohibited (except to other
members of the predisclosure list).

ADDITIONALLY, deployment of the grant table v2 disabling mitigation
described above *is* now (following the public release of XSA-379)
permitted during the embargo on public-facing systems with untrusted
guest users and administrators.  This is because (although such a
configuration change is recognizable by the affected guests) it is a
mitigation recommended in XSA-379, so such a change would not reveal
the existence of a further problem.

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-----

iQE/BAEBCAAqFiEEI+MiLBRfRHX6gGCng/4UyVfoK9kFAmE4rD4MHHBncEB4ZW4u
b3JnAAoJEIP+FMlX6CvZ8S8H+ITq1u5AaK+N1wgsgztLJRh1cjFTDaLZdI0mypwV
+wPhNdw1FFH19wYDZhOJIzv3h5352YVUYs8P6HvhFWrsUaq5n4cz17wxUHch74r3
MUUU9WUdTffQrAAOSSK65yWTUewv/FglEWP55YFBDPqBJHpVWt2MMidmP6My6azK
GZAHSWU7+qNXbs4/OM+dQJyUJm6yZtAltVtVmiJdJ5bSZyqe+82zRMnS39jlkZEh
VwFnw6rdlPcYO/fNYi25bQSlXbFeruSJYK+omrrFsyd65Z4D5LyZc5CQkfRJgEt6
vMDsQR+5hrE/KXKr2mfyTx6nh0RdR8kcI2Wh017BYuLqhA==
=AEo5
-----END PGP SIGNATURE-----


Xenproject.org Security Team