Bug 1940609 (CVE-2021-28687) - CVE-2021-28687 xen: HVM soft-reset crashes toolstack (XSA-368)
Summary: CVE-2021-28687 xen: HVM soft-reset crashes toolstack (XSA-368)
Keywords:
Status: CLOSED NOTABUG
Alias: CVE-2021-28687
Product: Security Response
Classification: Other
Component: vulnerability
Version: unspecified
Hardware: All
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Red Hat Product Security
QA Contact:
URL:
Whiteboard:
Depends On: 1940610
Blocks: 1940611
TreeView+ depends on / blocked
 
Reported: 2021-03-18 17:42 UTC by Pedro Sampaio
Modified: 2021-03-19 12:38 UTC (History)
3 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2021-03-18 19:51:48 UTC


Attachments (Terms of Use)

Description Pedro Sampaio 2021-03-18 17:42:30 UTC
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

            Xen Security Advisory CVE-2021-28687 / XSA-368
                              version 3

                   HVM soft-reset crashes toolstack

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

CVE assigned.

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

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

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.

IMPACT
======

A malicious guest can crash the management daemon, leading to at least
a localized, possibly system-wide denial-of-service.

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

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
not affected.

MITIGATION
==========

Ensuring that any management daemons are restarted automatically after
a crash will partially mitigate the issue.

CREDITS
=======

This issue was discovered by Olaf Hering.

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.

xsa368.patch           xen-unstable
xsa368-4.14.patch      Xen 4.14.x
xsa368-4.13.patch      Xen 4.13.x - Xen 4.12.x

$ sha256sum xsa368*
e80f33c3ce45372fef7bd91ec71b2b66e557176b79f9771872ce111bfff34150  xsa368.meta
b82f2b110514cdf47a2688913ad5af68b01050751d56705a15ddf9a970b6fa0d  xsa368.patch
636df70ae5eaf00b50ef0b5ac219a2aeda771c66833fae88e7ee43b18ae889f4  xsa368-4.13.patch
55bbe59c75b69f493e364dfcf6cdbc7db4acd32dbf0b4d2466815b7c1f1823ce  xsa368-4.14.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.

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.

Comment 1 Pedro Sampaio 2021-03-18 17:43:14 UTC
Created xen tracking bugs for this issue:

Affects: fedora-all [bug 1940610]

Comment 2 Product Security DevOps Team 2021-03-18 19:51:48 UTC
This CVE Bugzilla entry is for community support informational purposes only as it does not affect a package in a commercially supported Red Hat product. Refer to the dependent bugs for status of those individual community products.


Note You need to log in before you can comment on or make changes to this bug.