Headline
CVE-2020-29569: 350 - Xen Security Advisories
An issue was discovered in the Linux kernel through 5.10.1, as used with Xen through 4.14.x. 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 toggles between the states connect and disconnect. As a consequence, the block backend may re-use a pointer after it was freed. A misbehaving guest can trigger a dom0 crash by continuously connecting / disconnecting a block frontend. Privilege escalation and information leaks cannot be ruled out. This only affects systems with a Linux blkback.
Information
Advisory
XSA-350
Public release
2020-12-15 12:00
Updated
2020-12-15 12:19
Version
4
CVE(s)
CVE-2020-29569
Title
Use after free triggered by block frontend in Linux blkback
Filesadvisory-350.txt (signed advisory file)
xsa350-linux.patchAdvisory
-----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-----
Xenproject.org Security Team
Related news
Pexip Infinity 27 before 28.0 allows remote attackers to trigger excessive resource consumption and termination because of registrar resource mishandling.
Pexip Infinity before 28.1 allows remote attackers to trigger a software abort via G.719.
Pexip Infinity 27.x before 27.2 has Improper Access Control. An attacker can sometimes join a conference (call join) if it has a lock but not a PIN.
Pexip Infinity 27.x before 27.3 allows remote attackers to trigger a software abort via single-sign-on if a random Universally Unique Identifier is guessed.
Pexip Infinity 27.x before 27.3 has Improper Input Validation. The client API allows remote attackers to trigger a software abort via a gateway call into Teams.
Pexip Infinity before 27.3 allows remote attackers to trigger a software abort via One Touch Join.
Pexip Infinity before 27.3 allows remote attackers to trigger a software abort via H.323.
Pexip Infinity 27.x before 27.3 allows remote attackers to trigger a software abort via the Session Initiation Protocol.
Pexip Infinity 27.x before 27.3 allows remote attackers to trigger a software abort via HTTP.
Pexip Infinity before 27.3 allows remote attackers to trigger a software abort, and possibly enumerate usernames, via One Touch Join.