diff options
author | Leo Famulari <leo@famulari.name> | 2017-11-08 21:04:33 -0500 |
---|---|---|
committer | Leo Famulari <leo@famulari.name> | 2017-11-10 12:16:31 -0500 |
commit | adf7e69cab6180ef75360a1c0731c93f4bff2b18 (patch) | |
tree | 7cf0da9738e88fe7bb132a85636fccc315b1a9ba /gnu/packages/patches/qemu-CVE-2017-15268.patch | |
parent | d4d7d70912642be18d93c9ce6470f8650097b5e5 (diff) | |
download | guix-adf7e69cab6180ef75360a1c0731c93f4bff2b18.tar.gz |
gnu: qemu: Fix CVE-2017-{15038,15268,15289}.
* gnu/packages/patches/qemu-CVE-2017-15038.patch, gnu/packages/patches/qemu-CVE-2017-15268.patch, gnu/packages/patches/qemu-CVE-2017-15289.patch: New files. * gnu/local.mk (dist_patch_DATA): Add them. * gnu/packages/virtualization.scm (qemu)[source]: Use them.
Diffstat (limited to 'gnu/packages/patches/qemu-CVE-2017-15268.patch')
-rw-r--r-- | gnu/packages/patches/qemu-CVE-2017-15268.patch | 62 |
1 files changed, 62 insertions, 0 deletions
diff --git a/gnu/packages/patches/qemu-CVE-2017-15268.patch b/gnu/packages/patches/qemu-CVE-2017-15268.patch new file mode 100644 index 0000000000..8238c3059f --- /dev/null +++ b/gnu/packages/patches/qemu-CVE-2017-15268.patch @@ -0,0 +1,62 @@ +Fix CVE-2017-15268: + +https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-15268 + +Patch copied from upstream source repository: + +https://git.qemu.org/?p=qemu.git;a=commitdiff;h=a7b20a8efa28e5f22c26c06cd06c2f12bc863493 + +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.15.0 + |