-----BEGIN PGP SIGNED MESSAGE-----
AUSCERT External Security Bulletin Redistribution
HVM soft-reset crashes toolstack
19 March 2021
AusCERT Security Bulletin Summary
Operating System: Linux variants
Impact/Access: Denial of Service -- Unknown/Unspecified
CVE Names: CVE-2021-28687
- --------------------------BEGIN INCLUDED TEXT--------------------
- -----BEGIN PGP SIGNED MESSAGE-----
Xen Security Advisory CVE-2021-28687 / XSA-368
HVM soft-reset crashes toolstack
UPDATES IN VERSION 3
libxl requires all data structures passed across its public interface
to be initialized before use and disposed of afterwards by calling a
specific set of functions. Many internal data structures also require
this initialize / dispose discipline, but not all of them.
When the "soft reset" feature was implemented, the
libxl__domain_suspend_state structure didn't require any
initialization or disposal. At some point later, an initialization
function was introduced for the structure; but the "soft reset" path
wasn't refactored to call the initialization function. When a guest
nwo initiates a "soft reboot", uninitialized data structure leads to
an assert() when later code finds the structure in an unexpected
The effect of this is to crash the process monitoring the guest. How
this affects the system depends on the structure of the toolstack.
For xl, this will have no security-relevant effect: every VM has its
own independent monitoring process, which contains no state. The
domain in question will hang in a crashed state, but can be destroyed
by `xl destroy` just like any other non-cooperating domain.
For daemon-based toolstacks linked against libxl, such as libvirt,
this will crash the toolstack, losing the state of any in-progress
operations (localized DoS), and preventing further administrator
operations unless the daemon is configured to restart automatically
(system-wide DoS). If crashes "leak" resources, then repeated crashes
could use up resources, also causing a system-wide DoS.
A malicious guest can crash the management daemon, leading to at least
a localized, possibly system-wide denial-of-service.
Only Xen versions 4.12 through 4.14 are affected. Earlier versions
are not affected.
The issue affects only systems with a guest monitoring process, which
is linked against libxl, and which is important other than simply for
the functioning of one particular guest. libvirt is one common
toolstack affected. Systems using the `xl` command-line tool should
generally suffer no security-relevant effects.
The xapi toolstack does not currently link against libxl, and so is
Ensuring that any management daemons are restarted automatically after
a crash will partially mitigate the issue.
This issue was discovered by Olaf Hering.
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.
xsa368-4.14.patch Xen 4.14.x
xsa368-4.13.patch Xen 4.13.x - Xen 4.12.x
$ sha256sum xsa368*
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
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 firstname.lastname@example.org
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: email@example.com
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-----