[prev in list] [next in list] [prev in thread] [next in thread] 

List:       oss-security
Subject:    [oss-security] Xen Security Advisory 184 (CVE-2016-5403) - virtio: unbounded memory allocation issue
From:       Xen.org security team <security () xen ! org>
Date:       2016-07-27 16:06:53
Message-ID: E1bSRMD-0006Jd-Sq () xenbits ! xenproject ! org
[Download RAW message or body]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

            Xen Security Advisory CVE-2016-5403 / XSA-184
                              version 2

               virtio: unbounded memory allocation issue

UPDATES IN VERSION 2
====================

Public release.

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

A guest can submit virtio requests without bothering to wait for
completion and is therefore not bound by virtqueue size.  (This
requires reusing vring descriptors in more than one request, which is
incorrect but possible.)  Processing a request allocates a
VirtQueueElement and therefore causes unbounded memory allocation
controlled by the guest.

IMPACT
======

A malicious guest administrator can cause unbounded memory allocation
in QEMU, which can cause an Out-of-Memory condition in the domain
running qemu.

Thus, a malicious guest administrator can cause a denial of service
affecting the whole host.

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

ARM systems are not vulnerable.

PV domains are not vulnerable.

Only HVM domains where virtio-net devices are provided to the guest
are vulnerable.  Note that NO such devices are provided by default,
so the default configuration is not vulnerable.

HVM domains run with QEMU stub domains are not vulnerable.

(Note that all virtio subsystems are affected; but only virtio-net is
a supported configuration.  See docs/misc/qemu-xen-security.)

MITIGATION
==========

Running PV only will avoid the issue.

Running HVM domains with Xen PV drivers instead of virtio-net will
avoid the issue.

Running HVM domains with with stubdomains will mitigate the issue.

CREDITS
=======

This issue was discovered by Zhenhao Hong of the 360 Marvel Team.

RESOLUTION
==========

Applying the appropriate attached patch resolves this issue.

xsa184-qemuu-master.patch  qemu-upstream, Xen unstable, 4.7.x, 4.6.x, 4.5.x, 4.4.x
xsa184-qemut-master.patch  qemu-traditional, Xen unstable, 4.7.x, 4.6.x, 4.5.x, 4.4.x

$ sha256sum xsa184*
ea41a25dac82cc5c0ef8e599feb6ed400e99414110d4dba8017d6bd048bc3de4  xsa184-qemut-master.patch
2d675e5e08d9443cf2e5f3aa37521241d6ed898a602b5111d6969023e67b9b6b  xsa184-qemuu-master.patch
$

NOTES ON THE EMBARGO PERIOD
===========================

Note that the embargo period is shorter than normal as the Xen
Security team were only notified of the issue on 25 July.

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

Deployment of the patches and/or mitigations 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).

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-----
Version: GnuPG v1

iQEcBAEBAgAGBQJXmNwVAAoJEIP+FMlX6CvZUUQIAMMpYEr4wyoPEWe1w/4TrtQt
eTaDbBFFblfuHOTQcXZephlWBtSZ1bHbdEiTsQnflBYWLLiZZP1tud0f3MvN03uN
M9kTv1LsAb29NC19Oy1w02AOVXm0XklA3JbFG5OoidWVYra0UQSFKeZvi8Tlqr5C
ry2+jdErRGHsQFkjecBU0zSqXmz0+rcTlpzHtfJw3We3J9J4A1WPfAjXN3dL81yx
Tdl3P2heokhR2jsZgi7ZgIBo/s4rD4wbRD5gL4pf6eokyJIib7NFhctMi8hLDkTL
RbJh7sb+U9G5B2arMhRE7e00v7PgSfh+ossBQljszWhbHHCctggmGGIqWF0AvuQ=
=+1d1
-----END PGP SIGNATURE-----

["xsa184-qemut-master.patch" (application/octet-stream)]

From 17d8c4e47dfb41cb6778520ff2eab7a11fe12dfd Mon Sep 17 00:00:00 2001
From: P J P <ppandit@redhat.com>
Date: Tue, 26 Jul 2016 15:31:59 +0100
Subject: [PATCH] virtio: error out if guest exceeds virtqueue size

A broken or malicious guest can submit more requests than the virtqueue
size permits.

The guest can submit requests without bothering to wait for completion
and is therefore not bound by virtqueue size.  This requires reusing
vring descriptors in more than one request, which is incorrect but
possible.  Processing a request allocates a VirtQueueElement and
therefore causes unbounded memory allocation controlled by the guest.

Exit with an error if the guest provides more requests than the
virtqueue size permits.  This bounds memory allocation and makes the
buggy guest visible to the user.

Reported-by: Zhenhao Hong <zhenhaohong@gmail.com>
Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
---
 hw/virtio.c | 5 +++++
 1 file changed, 5 insertions(+)

diff --git a/hw/virtio.c b/hw/virtio.c
index c26feff..42897bf 100644
--- a/hw/virtio.c
+++ b/hw/virtio.c
@@ -421,6 +421,11 @@ int virtqueue_pop(VirtQueue *vq, VirtQueueElement *elem)
     /* When we start there are none of either input nor output. */
     elem->out_num = elem->in_num = 0;
 
+    if (vq->inuse >= vq->vring.num) {
+        fprintf(stderr, "Virtqueue size exceeded");
+        exit(1);
+    }
+
     i = head = virtqueue_get_head(vq, vq->last_avail_idx++);
     do {
         struct iovec *sg;
-- 
2.1.4


["xsa184-qemuu-master.patch" (application/octet-stream)]

From e469db25d6b2e5c71cd15451889226641c53a5cd Mon Sep 17 00:00:00 2001
From: P J P <ppandit@redhat.com>
Date: Mon, 25 Jul 2016 17:37:18 +0530
Subject: [PATCH] virtio: error out if guest exceeds virtqueue size

A broken or malicious guest can submit more requests than the virtqueue
size permits.

The guest can submit requests without bothering to wait for completion
and is therefore not bound by virtqueue size.  This requires reusing
vring descriptors in more than one request, which is incorrect but
possible.  Processing a request allocates a VirtQueueElement and
therefore causes unbounded memory allocation controlled by the guest.

Exit with an error if the guest provides more requests than the
virtqueue size permits.  This bounds memory allocation and makes the
buggy guest visible to the user.

Reported-by: Zhenhao Hong <zhenhaohong@gmail.com>
Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
---
 hw/virtio/virtio.c | 5 +++++
 1 file changed, 5 insertions(+)

diff --git a/hw/virtio/virtio.c b/hw/virtio/virtio.c
index d24f775..f8ac0fb 100644
--- a/hw/virtio/virtio.c
+++ b/hw/virtio/virtio.c
@@ -483,6 +483,11 @@ int virtqueue_pop(VirtQueue *vq, VirtQueueElement *elem)
 
     max = vq->vring.num;
 
+    if (vq->inuse >= max) {
+        error_report("Virtqueue size exceeded");
+        exit(1);
+    }
+
     i = head = virtqueue_get_head(vq, vq->last_avail_idx++);
     if (virtio_vdev_has_feature(vdev, VIRTIO_RING_F_EVENT_IDX)) {
         vring_set_avail_event(vq, vq->last_avail_idx);
-- 
2.1.4



[prev in list] [next in list] [prev in thread] [next in thread]