Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [day] [month] [year] [list]
Date: Tue, 22 Sep 2020 13:37:16 +0000
From: security team <>
CC: security team <>
Subject: Xen Security Advisory 338 v4 (CVE-2020-25597) - once valid event
 channels may not turn invalid

Hash: SHA256

            Xen Security Advisory CVE-2020-25597 / XSA-338
                               version 4

            once valid event channels may not turn invalid


Public release.


Logic in the handling of event channel operations in Xen assumes that an
event channel, once valid, will not become invalid over the life time of
a guest.  However, operations like the resetting of all event channels
may involve decreasing one of the bounds checked when determining
validity.  This may lead to bug checks triggering, crashing the host.


An unprivileged guest may be able to crash Xen, leading to a Denial of
Service (DoS) for the entire system.


All Xen versions from 4.4 onwards are vulnerable.  Xen versions 4.3 and
earlier are not vulnerable.

Only systems with untrusted guests permitted to create more than the
default number of event channels are vulnerable.  This number depends
on the architecture and type of guest.  For 32-bit x86 PV guests, this
is 1023; for 64-bit x86 PV guests, and for all ARM guests, this number
is 4095.  Systems where untrusted guests are limited to fewer than
this number are not vulnerable.

Note that xl and libxl limit max_event_channels to 1023 by default, so
systems using exlusively xl, libvirt+libxl, or their own toolstack
based on libxl, and not explicitly setting max_event_channels, are not


The problem can be avoided by reducing the number of event channels
available to the guest to no more than 1023.  For example, setting
"max_event_channels=1023" in the xl domain configuration, or deleting
any existing setting (since 1023 is the default for xl/libxl).

For ARM systems, any limit no more than 4095 is safe.

For 64-bit x86 PV guests, any limit no more than 4095 is likewise safe
if the host configuration prevents the guest administrator from
substituting and running a 32-bit kernel (and thereby putting the
guest into 32-bit PV mode).


This issue was discovered by Jan Beulich of SUSE.


Applying the 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.

xsa338.patch           Xen 4.10 - xen-unstable

$ sha256sum xsa338*
56c322b89a96db6be40cf15fdb9303e24ff692aa5a6274b2d7718bfc05acf309  xsa338.meta
7345eac1cbad23b082523e9cbd0331f8a9f16c6e459fb2a686606253f5514c9b  xsa338.patch


Deployment of the *patch* 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).

And: deployment of the event channel limit reduction mitigation is NOT
permitted (except where all the affected systems and VMs are
administered and used only by organisations which are members of the
Xen Project Security Issues Predisclosure List).  Specifically,
deployment on public cloud systems is NOT permitted.

This is because such a change can be visible to the guest, so it would
leak the preconditions for the vulnerability and maybe lead to

Deployment of this, or similar mitigations, is permitted only AFTER
the embargo ends.

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:


Download attachment "xsa338.meta" of type "application/octet-stream" (1959 bytes)

Download attachment "xsa338.patch" of type "application/octet-stream" (1737 bytes)

Powered by blists - more mailing lists

Please check out the Open Source Software Security Wiki, which is counterpart to this mailing list.

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.