Information

Files

Advisory

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

            Xen Security Advisory CVE-2021-28698 / XSA-380
                               version 3

              long running loops in grant table handling

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

New bugfix patch on top of the prior set.

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

In order to properly monitor resource use, Xen maintains information on
the grant mappings a domain may create to map grants offered by other
domains.  In the process of carrying out certain actions, Xen would
iterate over all such entries, including ones which aren't in use
anymore and some which may have been created but never used.  If the
number of entries for a given domain is large enough, this iterating of
the entire table may tie up a CPU for too long, starving other domains
or causing issues in the hypervisor itself.

Note that a domain may map its own grants, i.e. there is no need for
multiple domains to be involved here.  A pair of "cooperating" guests
may, however, cause the effects to be more severe.

IMPACT
======

Malicious or buggy guest kernels may be able to mount a Denial of
Service (DoS) attack affecting the entire system.

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

All Xen versions from at least 3.2 onwards are vulnerable in principle.

Systems running with default settings are generally believed to not be
vulnerable.

MITIGATION
==========

The problem can be avoided by reducing the number of grant mappings Xen
would allow guests to establish.  For example, setting
"gnttab_max_maptrack_frames=256" on the Xen command line (available
from Xen 4.5 onwards) or "max_maptrack_frames=256" in the xl domain
configurations (available from Xen 4.10 onwards) may be low enough for
all hardware Xen is able to run on.  Note that except for driver
domains, guests don't normally have a need to establish grant mappings,
i.e. they may be okay to run with "max_maptrack_frames=0" in their xl
domain configurations.

- From Xen 4.14 onwards it is also possible to alter the system wide upper
bound of the number of grant mappings Xen would allow guests to
establish by writing to the /params/gnttab_max_maptrack_frames
hypervisor file system node.  Note however that changing the value this
way will only affect guests yet to be created on the respective host.

CREDITS
=======

This issue was discovered by Andrew Cooper of Citrix.

RESOLUTION
==========

Applying the appropriate pair of attached patches 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.

To address an issue observed with some compiler versions, another patch
needs to be applied on top. This has been committed to the unstable
tree (commit hash b6da9d0414d69c2682214ee3ecf9816fcac500d0) only so far.
This patch is listed last below.

xsa380/xsa380-[12].patch        xen-unstable - Xen 4.15.x
xsa380/xsa380-4.14-?.patch      Xen 4.14.x
xsa380/xsa380-4.13-?.patch      Xen 4.13.x
xsa380/xsa380-4.12-?.patch      Xen 4.12.x
xsa380/xsa380-4.11-?.patch      Xen 4.11.x
xsa380/xsa380-3.patch           Xen 4.15.x - Xen 4.11.x

$ sha256sum xsa380* xsa380*/*
3b1938277665c195f6822a1170c50a853efa6bc3dcd6b2b0b9bbb0849a57bbf6  xsa380.meta
65411a0fd05d534ed2238b259aa2877331ac0e79f2dda80b424f34fffcce108a  xsa380/xsa380-1.patch
e6cd6d345abaad38e10d6f680fe881e874e35a7295199e5430bacd209f0b7304  xsa380/xsa380-2.patch
1ead53a28dedb0a502a700d9ea933e89e385c1582f4790f558a11d0d39e9d374  xsa380/xsa380-3.patch
f3b486aa99a75ab54f9e26e21a721a413f993b27dbc3e6f2fda976fe20ddbae3  xsa380/xsa380-4.11-1.patch
96a09c05ca87fe3590064ca6d269ca47b97c732401cb593ff1068ac91009f51a  xsa380/xsa380-4.11-2.patch
496063cd4641258e1854a77f626cdd86c866c3ed8603bdc2ff9ab709008c84a7  xsa380/xsa380-4.12-1.patch
d850e1263e89c7a718f2cddcfb639fe4a5095a1852fc35499ed16a4075d225e5  xsa380/xsa380-4.12-2.patch
c23d34527a2ec68015ad78cd90365e4d80bce842ce01eeaa8cd2246021a55693  xsa380/xsa380-4.13-1.patch
bd40ce749d02f343c79325488ac1348e1c9e88e698bbad351bdb0a0d3995f3e0  xsa380/xsa380-4.13-2.patch
9b06085f9a4b93c465563cd76fdc682ddb9dba968c214259425b234e7053a809  xsa380/xsa380-4.14-1.patch
bf6b53880abd53b56226080d1a32839c7c8c459867104697cd76eeafc2ea382a  xsa380/xsa380-4.14-2.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.  HOWEVER, care has to be taken to avoid restricting
guests too much, as them suddenly being unable to map grants they used
to be able to map may lead to re-discovery of the issue.

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/4UyVfoK9kFAmEvSDUMHHBncEB4ZW4u
b3JnAAoJEIP+FMlX6CvZfboH/jtTLKbkb/K4SPliIDSRym1+wx17Ho30F9IRfd7E
ZdUBHfFLTEbZ/GvU+UkU914XeK49fCHZGylu2dcIRWgPmXFlqOtydFJny9a8sCjx
7/dLR1WXvhJ4eG8Hsma13uRzZuaF4JdXDp1M/QOr6aBHNTLBgMefbQNTAbFO0kzP
2xK3arGefi/eNa3GOEghrMlt2U/5r1h7PfLXBl69BETomOCOo5gyn6aQwqH/xKSY
W2cmqN0hYLyQSA+jx6QuTknsvSLS6NWWPEk/xfs31Op0E/P3tga0u6hCbRvWzOmE
AdISyyP8ogIBU4ekMn0H4yQoWKVgYctk3XAawBmogv+VJXI=
=7wyB
-----END PGP SIGNATURE-----