[prev in list] [next in list] [prev in thread] [next in thread]
List: xen-announce
Subject: [Xen-announce] Xen Security Advisory 71 (CVE-2013-4375) - qemu disk backend (qdisk) resource leak
From: Xen.org security team <security () xen ! org>
Date: 2013-10-10 12:28:25
Message-ID: E1VUFLt-0002yY-AA () xenbits ! xen ! org
[Download RAW message or body]
-----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-----
["xsa71-qemu-xen-4.2.patch" (application/octet-stream)]
From 23260e589e52ec83349f22198eab2331b5a1684e Mon Sep 17 00:00:00 2001
From: Matthew Daley <mattjd@gmail.com>
Date: Wed, 25 Sep 2013 12:28:47 +1200
Subject: [PATCH] xen_disk: mark ioreq as mapped before unmapping in error
case
Commit c6961b7d ("xen_disk: use bdrv_aio_flush instead of bdrv_flush")
modified the semantics of ioreq_{un,}map so that they are idempotent if
called when they're not needed (ie., twice in a row). However, it neglected
to handle the case where batch mapping is not being used (the default), and
one of the grants fails to map. In this case, ioreq_unmap will be called to
unwind and unmap any mappings already performed, but ioreq_unmap simply
returns due to the aforementioned change (the ioreq has not already been
marked as mapped).
The frontend user can therefore force xen_disk to leak grant mappings, a
per-backend-domain limited resource.
Fix by marking the ioreq as mapped before calling ioreq_unmap in this
situation.
This is XSA-71 / CVE-2013-4375
Signed-off-by: Matthew Daley <mattjd@gmail.com>
---
hw/xen_disk.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/hw/xen_disk.c b/hw/xen_disk.c
index a402ac8..1cdfcbc 100644
--- a/hw/xen_disk.c
+++ b/hw/xen_disk.c
@@ -299,6 +299,7 @@ static int ioreq_map(struct ioreq *ioreq)
xen_be_printf(&ioreq->blkdev->xendev, 0,
"can't map grant ref %d (%s, %d maps)\n",
ioreq->refs[i], strerror(errno), ioreq->blkdev->cnt_map);
+ ioreq->mapped = 1;
ioreq_unmap(ioreq);
return -1;
}
--
1.7.10.4
["xsa71-qemu-xen-unstable.patch" (application/octet-stream)]
From 23260e589e52ec83349f22198eab2331b5a1684e Mon Sep 17 00:00:00 2001
From: Matthew Daley <mattjd@gmail.com>
Date: Wed, 25 Sep 2013 12:28:47 +1200
Subject: [PATCH] xen_disk: mark ioreq as mapped before unmapping in error
case
Commit c6961b7d ("xen_disk: use bdrv_aio_flush instead of bdrv_flush")
modified the semantics of ioreq_{un,}map so that they are idempotent if
called when they're not needed (ie., twice in a row). However, it neglected
to handle the case where batch mapping is not being used (the default), and
one of the grants fails to map. In this case, ioreq_unmap will be called to
unwind and unmap any mappings already performed, but ioreq_unmap simply
returns due to the aforementioned change (the ioreq has not already been
marked as mapped).
The frontend user can therefore force xen_disk to leak grant mappings, a
per-backend-domain limited resource.
Fix by marking the ioreq as mapped before calling ioreq_unmap in this
situation.
This is XSA-71 / CVE-2013-4375
Signed-off-by: Matthew Daley <mattjd@gmail.com>
---
hw/xen_disk.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/hw/xen_disk.c b/hw/xen_disk.c
index a402ac8..1cdfcbc 100644
--- a/hw/xen_disk.c
+++ b/hw/xen_disk.c
@@ -299,6 +299,7 @@ static int ioreq_map(struct ioreq *ioreq)
xen_be_printf(&ioreq->blkdev->xendev, 0,
"can't map grant ref %d (%s, %d maps)\n",
refs[i], strerror(errno), ioreq->blkdev->cnt_map);
+ ioreq->mapped = 1;
ioreq_unmap(ioreq);
return -1;
}
--
1.7.10.4
_______________________________________________
Xen-announce mailing list
Xen-announce@lists.xen.org
http://lists.xen.org/xen-announce
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic