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

            Xen Security Advisory CVE-2020-29569 / XSA-350
                               version 4

      Use after free triggered by block frontend in Linux blkback

UPDATES IN VERSION 4
====================

Public release.

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

The Linux kernel PV block backend expects the kernel thread handler
to reset ring->xenblkd to NULL when stopped. However, the handler may
not have time to run if the frontend quickly toggle between the states
connect and disconnect.

As a consequence, the block backend may re-use a pointer after it was
freed.

IMPACT
======

A misbehaving guest can trigger a dom0 crash by continuously
connecting / disconnecting a block frontend. Privileged escalation and
information leak cannot be ruled out.

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

Systems using Linux blkback are vulnerable.  This includes most
systems with a Linux dom0, or Linux driver domains.

Linux versions containing a24fa22ce22a ("xen/blkback: don't use
xen_blkif_get() in xen-blkback kthread"), or its backports, are
vulnerable.  This includes all current linux-stable branches back to
at least linux-stable/linux-4.4.y.

When the Xen PV block backend is provided by userspace (eg qemu), that
backend is not vulnerable.  So configurations where the xl.cfg domain
configuration file specifies all disks with backendtype="qdisk" are
not vulnerable.

The Linux blkback only supports raw format images, so when all disks
have a format than format="raw", the system is not vulnerable.

MITIGATION
==========

Switching the disk backend to qemu with backendtype="qdisk" will avoid
the vulnerability.  This mitigation is not always available, depending
on the other aspects of the configuration.

CREDITS
=======

This issue was discovered by Olivier Benjamin and Pawel Wieczorkiewicz of
Amazon.

RESOLUTION
==========

Applying the appropriate attached patch resolves this issue.

xsa350-linux.patch     Linux

$ sha256sum xsa350*
46e8141bcfd21629043df0af4d237d6c264b27c1137fc84d4a1127ace30926c4  xsa350-linux.patch
$

DEPLOYMENT DURING EMBARGO
=========================

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


Deployment of the mitigation to change the block backend 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 this is a guest-visible change, which will indicate
that it is the block backend which has a vulnerability.

Deployment 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
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-----

iQE/BAEBCAAqFiEEI+MiLBRfRHX6gGCng/4UyVfoK9kFAl/Yqd8MHHBncEB4ZW4u
b3JnAAoJEIP+FMlX6CvZRusH9RGJFExFzCDQ/y99mvchhcIXGf4g0V373W9YrPAF
zUIiKBGEWuE07tY9YVKV5ocNnPQNdGwsnKJXPsFJAjW4DTDyL00e0yFUNQ7c1kTl
vdRgh0D5VtzIcaiqIC/4GjRzuBTQ3d9gTSOzJGhBS0yoIsZTSr5KyJBAiw1Slz7Y
IHmLZawGdQrDF6YpGLEXPRM7TxNNLn0wPqpPTxC+qMnTThdLuogf4HWLae7xHqX+
Q8b6KYxnkouq5sOddESglf+Gh+j9JHoLCIRm3XA4LrtGtQoUrvdqeS8rklRPH7Xk
yGP99M+J++KMx02ZJJUNrJmtSExDl35liz84qRiRfcKpxQ==
=qnB/
-----END PGP SIGNATURE-----