-----BEGIN PGP SIGNED MESSAGE-----
AUSCERT External Security Bulletin Redistribution
New Xen bulletin: long running loops in grant table handling
26 August 2021
AusCERT Security Bulletin Summary
Operating System: Xen
Impact/Access: Denial of Service -- Existing Account
CVE Names: CVE-2021-28698
- --------------------------BEGIN INCLUDED TEXT--------------------
- -----BEGIN PGP SIGNED MESSAGE-----
Xen Security Advisory CVE-2021-28698 / XSA-380
long running loops in grant table handling
UPDATES IN VERSION 2
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.
Malicious or buggy guest kernels may be able to mount a Denial of
Service (DoS) attack affecting the entire system.
All Xen versions from at least 3.2 onwards are vulnerable in principle.
Systems running with default settings are generally believed to not be
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
- - 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.
This issue was discovered by Andrew Cooper of Citrix.
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.
xsa380/xsa380-.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
$ sha256sum xsa380* xsa380*/*
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
(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:
- -----BEGIN PGP SIGNATURE-----
- -----END PGP SIGNATURE-----
- --------------------------END INCLUDED TEXT--------------------
You have received this e-mail bulletin as a result of your organisation's
registration with AusCERT. The mailing list you are subscribed to is
maintained within your organisation, so if you do not wish to continue
receiving these bulletins you should contact your local IT manager. If
you do not know who that is, please send an email to email@example.com
and we will forward your request to the appropriate person.
NOTE: Third Party Rights
This security bulletin is provided as a service to AusCERT's members. As
AusCERT did not write the document quoted above, AusCERT has had no control
over its content. The decision to follow or act on information or advice
contained in this security bulletin is the responsibility of each user or
organisation, and should be considered in accordance with your organisation's
site policies and procedures. AusCERT takes no responsibility for consequences
which may arise from following or acting on information or advice contained in
this security bulletin.
NOTE: This is only the original release of the security bulletin. It may
not be updated when updates to the original are made. If downloading at
a later date, it is recommended that the bulletin is retrieved directly
from the author's website to ensure that the information is still current.
Contact information for the authors of the original document is included
in the Security Bulletin above. If you have any questions or need further
information, please contact them directly.
Previous advisories and external security bulletins can be retrieved from:
Australian Computer Emergency Response Team
The University of Queensland
Internet Email: firstname.lastname@example.org
Facsimile: (07) 3365 7031
Telephone: (07) 3365 4417 (International: +61 7 3365 4417)
AusCERT personnel answer during Queensland business hours
which are GMT+10:00 (AEST).
On call after hours for member emergencies only.
-----BEGIN PGP SIGNATURE-----
-----END PGP SIGNATURE-----