Information
Advisory | XSA-71 |
Public release | 2013-10-10 12:00 |
Updated | 2013-10-10 12:28 |
Version | 2 |
CVE(s) | CVE-2013-4375 |
Title | qemu disk backend (qdisk) resource leak |
Files
advisory-71.txt (signed advisory file)
xsa71-qemu-xen-4.2.patch
xsa71-qemu-xen-unstable.patch
Advisory
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Xen Security Advisory CVE-2013-4375 / XSA-71
version 2
qemu disk backend (qdisk) resource leak
UPDATES IN VERSION 2
====================
Public release
Fix patch header corruption in xsa71-qemu-xen-unstable.patch.
ISSUE DESCRIPTION
=================
The qdisk PV disk backend in the qemu-xen flavour of qemu ("upstream
qemu") can be influenced by a malicious frontend to leak mapped grant
references.
IMPACT
======
A malicious HVM guest can cause the backend domain to run out of grant
references, leading to a DoS for any other domain which shares that
driver domain.
VULNERABLE SYSTEMS
==================
Any system which is using the qemu-xen qdisk backend for HVM guests is
vulnerable.
qemu-xen and qdisk are exposed by systems using libxl from Xen 4.2.0
onwards. In Xen 4.2.0 qemu-xen was a non-default option, from Xen
4.3.0 onwards qemu-xen is the default.
Xen 4.1.0 exposes qdisk via libxl but does not support qemu-xen and
therefore is not vulnerable.
The xend toolstack has never supported qdisk as a disk backend and
therefore such systems are not vulnerable.
Upstream qemu is vulnerable from version 1.1 onwards.
MITIGATION
==========
This vulnerability can be avoided by using a different block backend
(e.g. blkback or blktap2) or by using the qemu-xen-traditional version
of qemu.
Users of the xl toolstack, see docs/misc/xl-disk-configuration.txt for
information on forcing the use of a particular disk backend and
xl.cfg(5) for information on forcing the use of qemu-xen-traditional.
Systems which only run PV guests and/or run HVM guests without PV
drivers are not vulnerable.
CREDITS
=======
This issue was discovered by Coverity Scan and Matthew Daley.
RESOLUTION
==========
Applying the appropriate attached patch resolves this issue.
xsa71-qemu-xen-unstable.patch xen-unstable, Xen 4.3.x
xsa71-qemu-xen-4.2.patch Xen 4.2.x
$ sha256sum xsa71*.patch
a3f667e251a32fa5eff4a78eae49acd020b2f340fb203dc08a033d43841b0a2a xsa71-qemu-xen-4.2.patch
f5ec607babb01dc8f8065dfe121882af4c3d93c035bafbfed48825dea684d6d9 xsa71-qemu-xen-unstable.patch
$
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)
iQEcBAEBAgAGBQJSVp1bAAoJEIP+FMlX6CvZ8nMH/1sMYLD38viMSIJndL3Nlfz4
cj5AaTHyPIYaX3RzLZfM08+qeRIcXcPDAcNwaYn97IOv0JJ/gppfNOeCdmHGvWhl
z88vKbzI0RaDv3pL+eKo7RiGN/T32gsh6H4ltjrNGyO0LiDI4rfbxTBjVlzE8bB8
M4weAWtgEa7/VAYeM4g7cOoCD7goE15lYLSRsrQJGn/iizLdL/I+IqSvTaGwgE+I
yKvl7wJ1fEfy9sKCTls9INZdMnJXmlC4+Pq8phmW9QoSSIxNFqRDZ13IduXHbpXe
xyeAr7U5b5GzPtGclu6XX0vyuOct2mf984xHbe06ecJF2KjsXi44spszPP2elHQ=
=hcxy
-----END PGP SIGNATURE-----
Xenproject.org Security Team