app-emulation/qemu: Version bump to 2.10.1, various security fixes

Bug: https://bugs.gentoo.org/630432
Bug: https://bugs.gentoo.org/633822
Bug: https://bugs.gentoo.org/634070
Bug: https://bugs.gentoo.org/634148
Package-Manager: Portage-2.3.8, Repoman-2.3.4

3 files changed, 112 insertions, 80 deletions

diff --git a/app-emulation/qemu/files/qemu-2.10.0-CVE-2017-13711.patch b/app-emulation/qemu/files/qemu-2.10.0-CVE-2017-13711.patch
deleted file mode 100644
index 9d026568492d..000000000000
--- a/app-emulation/qemu/files/qemu-2.10.0-CVE-2017-13711.patch
+++ /dev/null
@@ -1,80 +0,0 @@
-From 1201d308519f1e915866d7583d5136d03cc1d384 Mon Sep 17 00:00:00 2001
-From: Samuel Thibault <samuel.thibault@ens-lyon.org>
-Date: Fri, 25 Aug 2017 01:35:53 +0200
-Subject: [PATCH] slirp: fix clearing ifq_so from pending packets
-MIME-Version: 1.0
-Content-Type: text/plain; charset=UTF-8
-Content-Transfer-Encoding: 8bit
-
-The if_fastq and if_batchq contain not only packets, but queues of packets
-for the same socket. When sofree frees a socket, it thus has to clear ifq_so
-from all the packets from the queues, not only the first.
-
-Signed-off-by: Samuel Thibault <samuel.thibault@ens-lyon.org>
-Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
-Cc: qemu-stable@nongnu.org
-Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
----
- slirp/socket.c | 39 +++++++++++++++++++++++----------------
- 1 file changed, 23 insertions(+), 16 deletions(-)
-
-diff --git a/slirp/socket.c b/slirp/socket.c
-index ecec0295a9..cb7b5b608d 100644
---- a/slirp/socket.c
-+++ b/slirp/socket.c
-@@ -60,29 +60,36 @@ socreate(Slirp *slirp)
- }
- 
- /*
-+ * Remove references to so from the given message queue.
-+ */
-+static void
-+soqfree(struct socket *so, struct quehead *qh)
-+{
-+    struct mbuf *ifq;
-+
-+    for (ifq = (struct mbuf *) qh->qh_link;
-+             (struct quehead *) ifq != qh;
-+             ifq = ifq->ifq_next) {
-+        if (ifq->ifq_so == so) {
-+            struct mbuf *ifm;
-+            ifq->ifq_so = NULL;
-+            for (ifm = ifq->ifs_next; ifm != ifq; ifm = ifm->ifs_next) {
-+                ifm->ifq_so = NULL;
-+            }
-+        }
-+    }
-+}
-+
-+/*
-  * remque and free a socket, clobber cache
-  */
- void
- sofree(struct socket *so)
- {
-   Slirp *slirp = so->slirp;
--  struct mbuf *ifm;
- 
--  for (ifm = (struct mbuf *) slirp->if_fastq.qh_link;
--       (struct quehead *) ifm != &slirp->if_fastq;
--       ifm = ifm->ifq_next) {
--    if (ifm->ifq_so == so) {
--      ifm->ifq_so = NULL;
--    }
--  }
--
--  for (ifm = (struct mbuf *) slirp->if_batchq.qh_link;
--       (struct quehead *) ifm != &slirp->if_batchq;
--       ifm = ifm->ifq_next) {
--    if (ifm->ifq_so == so) {
--      ifm->ifq_so = NULL;
--    }
--  }
-+  soqfree(so, &slirp->if_fastq);
-+  soqfree(so, &slirp->if_batchq);
- 
-   if (so->so_emu==EMU_RSH && so->extra) {
- 	sofree(so->extra);
--- 
-2.13.5
-
diff --git a/app-emulation/qemu/files/qemu-2.10.1-CVE-2017-15268.patch b/app-emulation/qemu/files/qemu-2.10.1-CVE-2017-15268.patch
new file mode 100644
index 000000000000..7d08b32b0272
--- /dev/null
+++ b/app-emulation/qemu/files/qemu-2.10.1-CVE-2017-15268.patch
@@ -0,0 +1,54 @@
+From a7b20a8efa28e5f22c26c06cd06c2f12bc863493 Mon Sep 17 00:00:00 2001
+From: "Daniel P. Berrange" <berrange@redhat.com>
+Date: Mon, 9 Oct 2017 14:43:42 +0100
+Subject: [PATCH] io: monitor encoutput buffer size from websocket GSource
+
+The websocket GSource is monitoring the size of the rawoutput
+buffer to determine if the channel can accepts more writes.
+The rawoutput buffer, however, is merely a temporary staging
+buffer before data is copied into the encoutput buffer. Thus
+its size will always be zero when the GSource runs.
+
+This flaw causes the encoutput buffer to grow without bound
+if the other end of the underlying data channel doesn't
+read data being sent. This can be seen with VNC if a client
+is on a slow WAN link and the guest OS is sending many screen
+updates. A malicious VNC client can act like it is on a slow
+link by playing a video in the guest and then reading data
+very slowly, causing QEMU host memory to expand arbitrarily.
+
+This issue is assigned CVE-2017-15268, publically reported in
+
+  https://bugs.launchpad.net/qemu/+bug/1718964
+
+Reviewed-by: Eric Blake <eblake@redhat.com>
+Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
+---
+ io/channel-websock.c | 4 ++--
+ 1 file changed, 2 insertions(+), 2 deletions(-)
+
+diff --git a/io/channel-websock.c b/io/channel-websock.c
+index d1d471f86e..04bcc059cd 100644
+--- a/io/channel-websock.c
++++ b/io/channel-websock.c
+@@ -28,7 +28,7 @@
+ #include <time.h>
+ 
+ 
+-/* Max amount to allow in rawinput/rawoutput buffers */
++/* Max amount to allow in rawinput/encoutput buffers */
+ #define QIO_CHANNEL_WEBSOCK_MAX_BUFFER 8192
+ 
+ #define QIO_CHANNEL_WEBSOCK_CLIENT_KEY_LEN 24
+@@ -1208,7 +1208,7 @@ qio_channel_websock_source_check(GSource *source)
+     if (wsource->wioc->rawinput.offset || wsource->wioc->io_eof) {
+         cond |= G_IO_IN;
+     }
+-    if (wsource->wioc->rawoutput.offset < QIO_CHANNEL_WEBSOCK_MAX_BUFFER) {
++    if (wsource->wioc->encoutput.offset < QIO_CHANNEL_WEBSOCK_MAX_BUFFER) {
+         cond |= G_IO_OUT;
+     }
+ 
+-- 
+2.13.6
+
diff --git a/app-emulation/qemu/files/qemu-2.10.1-CVE-2017-15289.patch b/app-emulation/qemu/files/qemu-2.10.1-CVE-2017-15289.patch
new file mode 100644
index 000000000000..a4ad2d5e4359
--- /dev/null
+++ b/app-emulation/qemu/files/qemu-2.10.1-CVE-2017-15289.patch
@@ -0,0 +1,58 @@
+From eb38e1bc3740725ca29a535351de94107ec58d51 Mon Sep 17 00:00:00 2001
+From: Gerd Hoffmann <kraxel@redhat.com>
+Date: Wed, 11 Oct 2017 10:43:14 +0200
+Subject: [PATCH] cirrus: fix oob access in mode4and5 write functions
+
+Move dst calculation into the loop, so we apply the mask on each
+interation and will not overflow vga memory.
+
+Cc: Prasad J Pandit <pjp@fedoraproject.org>
+Reported-by: Niu Guoxiang <niuguoxiang@huawei.com>
+Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
+Message-id: 20171011084314.21752-1-kraxel@redhat.com
+---
+ hw/display/cirrus_vga.c | 6 ++----
+ 1 file changed, 2 insertions(+), 4 deletions(-)
+
+diff --git a/hw/display/cirrus_vga.c b/hw/display/cirrus_vga.c
+index b4d579857a..bc32bf1e39 100644
+--- a/hw/display/cirrus_vga.c
++++ b/hw/display/cirrus_vga.c
+@@ -2038,15 +2038,14 @@ static void cirrus_mem_writeb_mode4and5_8bpp(CirrusVGAState * s,
+     unsigned val = mem_value;
+     uint8_t *dst;
+ 
+-    dst = s->vga.vram_ptr + (offset &= s->cirrus_addr_mask);
+     for (x = 0; x < 8; x++) {
++        dst = s->vga.vram_ptr + ((offset + x) & s->cirrus_addr_mask);
+ 	if (val & 0x80) {
+ 	    *dst = s->cirrus_shadow_gr1;
+ 	} else if (mode == 5) {
+ 	    *dst = s->cirrus_shadow_gr0;
+ 	}
+ 	val <<= 1;
+-	dst++;
+     }
+     memory_region_set_dirty(&s->vga.vram, offset, 8);
+ }
+@@ -2060,8 +2059,8 @@ static void cirrus_mem_writeb_mode4and5_16bpp(CirrusVGAState * s,
+     unsigned val = mem_value;
+     uint8_t *dst;
+ 
+-    dst = s->vga.vram_ptr + (offset &= s->cirrus_addr_mask);
+     for (x = 0; x < 8; x++) {
++        dst = s->vga.vram_ptr + ((offset + 2 * x) & s->cirrus_addr_mask & ~1);
+ 	if (val & 0x80) {
+ 	    *dst = s->cirrus_shadow_gr1;
+ 	    *(dst + 1) = s->vga.gr[0x11];
+@@ -2070,7 +2069,6 @@ static void cirrus_mem_writeb_mode4and5_16bpp(CirrusVGAState * s,
+ 	    *(dst + 1) = s->vga.gr[0x10];
+ 	}
+ 	val <<= 1;
+-	dst += 2;
+     }
+     memory_region_set_dirty(&s->vga.vram, offset, 16);
+ }
+-- 
+2.13.6
+