aboutsummaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorMarius Bakke <mbakke@fastmail.com>2017-12-19 01:15:09 +0100
committerMarius Bakke <mbakke@fastmail.com>2017-12-19 01:15:09 +0100
commit937790df9d9ed9f17d1807c7c0567ee71549d92b (patch)
tree2232cd5810f20111095d25f3217b6afff75ebb8b
parent2ea3333504b391ac7ad26a0b93aad3e18028a2ea (diff)
downloadpatches-937790df9d9ed9f17d1807c7c0567ee71549d92b.tar
patches-937790df9d9ed9f17d1807c7c0567ee71549d92b.tar.gz
gnu: qemu: Update to 2.10.2.
* gnu/packages/patches/qemu-CVE-2017-15118.patch, gnu/packages/patches/qemu-CVE-2017-15119.patch, gnu/packages/patches/qemu-CVE-2017-15268.patch: Delete files. * gnu/local.mk (dist_patch_DATA): Remove them. * gnu/packages/virtualization.scm (qemu): Update to 2.10.2. [source](patches): Remove obsolete.
-rw-r--r--gnu/local.mk3
-rw-r--r--gnu/packages/patches/qemu-CVE-2017-15118.patch58
-rw-r--r--gnu/packages/patches/qemu-CVE-2017-15119.patch68
-rw-r--r--gnu/packages/patches/qemu-CVE-2017-15268.patch62
-rw-r--r--gnu/packages/virtualization.scm7
5 files changed, 2 insertions, 196 deletions
diff --git a/gnu/local.mk b/gnu/local.mk
index 484449f72e..efb91fd826 100644
--- a/gnu/local.mk
+++ b/gnu/local.mk
@@ -1032,9 +1032,6 @@ dist_patch_DATA = \
%D%/packages/patches/python2-subprocess32-disable-input-test.patch \
%D%/packages/patches/python2-unittest2-remove-argparse.patch \
%D%/packages/patches/qemu-CVE-2017-15038.patch \
- %D%/packages/patches/qemu-CVE-2017-15118.patch \
- %D%/packages/patches/qemu-CVE-2017-15119.patch \
- %D%/packages/patches/qemu-CVE-2017-15268.patch \
%D%/packages/patches/qemu-CVE-2017-15289.patch \
%D%/packages/patches/qt4-ldflags.patch \
%D%/packages/patches/qtscript-disable-tests.patch \
diff --git a/gnu/packages/patches/qemu-CVE-2017-15118.patch b/gnu/packages/patches/qemu-CVE-2017-15118.patch
deleted file mode 100644
index d427317be9..0000000000
--- a/gnu/packages/patches/qemu-CVE-2017-15118.patch
+++ /dev/null
@@ -1,58 +0,0 @@
-Fix CVE-2017-15118:
-
-https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-15118
-https://bugzilla.redhat.com/show_bug.cgi?id=1516922
-
-Patch copied from upstream source repository:
-
-https://git.qemu.org/?p=qemu.git;a=commitdiff;h=51ae4f8455c9e32c54770c4ebc25bf86a8128183
-
-From 51ae4f8455c9e32c54770c4ebc25bf86a8128183 Mon Sep 17 00:00:00 2001
-From: Eric Blake <eblake@redhat.com>
-Date: Wed, 22 Nov 2017 15:07:22 -0600
-Subject: [PATCH] nbd/server: CVE-2017-15118 Stack smash on large export name
-
-Introduced in commit f37708f6b8 (2.10). The NBD spec says a client
-can request export names up to 4096 bytes in length, even though
-they should not expect success on names longer than 256. However,
-qemu hard-codes the limit of 256, and fails to filter out a client
-that probes for a longer name; the result is a stack smash that can
-potentially give an attacker arbitrary control over the qemu
-process.
-
-The smash can be easily demonstrated with this client:
-$ qemu-io f raw nbd://localhost:10809/$(printf %3000d 1 | tr ' ' a)
-
-If the qemu NBD server binary (whether the standalone qemu-nbd, or
-the builtin server of QMP nbd-server-start) was compiled with
--fstack-protector-strong, the ability to exploit the stack smash
-into arbitrary execution is a lot more difficult (but still
-theoretically possible to a determined attacker, perhaps in
-combination with other CVEs). Still, crashing a running qemu (and
-losing the VM) is bad enough, even if the attacker did not obtain
-full execution control.
-
-CC: qemu-stable@nongnu.org
-Signed-off-by: Eric Blake <eblake@redhat.com>
----
- nbd/server.c | 4 ++++
- 1 file changed, 4 insertions(+)
-
-diff --git a/nbd/server.c b/nbd/server.c
-index a81801e3bc..92c0fdd03b 100644
---- a/nbd/server.c
-+++ b/nbd/server.c
-@@ -386,6 +386,10 @@ static int nbd_negotiate_handle_info(NBDClient *client, uint32_t length,
- msg = "name length is incorrect";
- goto invalid;
- }
-+ if (namelen >= sizeof(name)) {
-+ msg = "name too long for qemu";
-+ goto invalid;
-+ }
- if (nbd_read(client->ioc, name, namelen, errp) < 0) {
- return -EIO;
- }
---
-2.15.0
-
diff --git a/gnu/packages/patches/qemu-CVE-2017-15119.patch b/gnu/packages/patches/qemu-CVE-2017-15119.patch
deleted file mode 100644
index 6265ecf8d6..0000000000
--- a/gnu/packages/patches/qemu-CVE-2017-15119.patch
+++ /dev/null
@@ -1,68 +0,0 @@
-Fix CVE-2017-15119:
-
-https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-15119
-https://bugzilla.redhat.com/show_bug.cgi?id=1516925
-
-Patch copied from upstream source repository:
-
-https://git.qemu.org/?p=qemu.git;a=commitdiff;h=fdad35ef6c5839d50dfc14073364ac893afebc30
-
-From fdad35ef6c5839d50dfc14073364ac893afebc30 Mon Sep 17 00:00:00 2001
-From: Eric Blake <eblake@redhat.com>
-Date: Wed, 22 Nov 2017 16:25:16 -0600
-Subject: [PATCH] nbd/server: CVE-2017-15119 Reject options larger than 32M
-
-The NBD spec gives us permission to abruptly disconnect on clients
-that send outrageously large option requests, rather than having
-to spend the time reading to the end of the option. No real
-option request requires that much data anyways; and meanwhile, we
-already have the practice of abruptly dropping the connection on
-any client that sends NBD_CMD_WRITE with a payload larger than 32M.
-
-For comparison, nbdkit drops the connection on any request with
-more than 4096 bytes; however, that limit is probably too low
-(as the NBD spec states an export name can theoretically be up
-to 4096 bytes, which means a valid NBD_OPT_INFO could be even
-longer) - even if qemu doesn't permit exports longer than 256
-bytes.
-
-It could be argued that a malicious client trying to get us to
-read nearly 4G of data on a bad request is a form of denial of
-service. In particular, if the server requires TLS, but a client
-that does not know the TLS credentials sends any option (other
-than NBD_OPT_STARTTLS or NBD_OPT_EXPORT_NAME) with a stated
-payload of nearly 4G, then the server was keeping the connection
-alive trying to read all the payload, tying up resources that it
-would rather be spending on a client that can get past the TLS
-handshake. Hence, this warranted a CVE.
-
-Present since at least 2.5 when handling known options, and made
-worse in 2.6 when fixing support for NBD_FLAG_C_FIXED_NEWSTYLE
-to handle unknown options.
-
-CC: qemu-stable@nongnu.org
-Signed-off-by: Eric Blake <eblake@redhat.com>
----
- nbd/server.c | 6 ++++++
- 1 file changed, 6 insertions(+)
-
-diff --git a/nbd/server.c b/nbd/server.c
-index 7d6801b427..a81801e3bc 100644
---- a/nbd/server.c
-+++ b/nbd/server.c
-@@ -673,6 +673,12 @@ static int nbd_negotiate_options(NBDClient *client, uint16_t myflags,
- }
- length = be32_to_cpu(length);
-
-+ if (length > NBD_MAX_BUFFER_SIZE) {
-+ error_setg(errp, "len (%" PRIu32" ) is larger than max len (%u)",
-+ length, NBD_MAX_BUFFER_SIZE);
-+ return -EINVAL;
-+ }
-+
- trace_nbd_negotiate_options_check_option(option,
- nbd_opt_lookup(option));
- if (client->tlscreds &&
---
-2.15.0
-
diff --git a/gnu/packages/patches/qemu-CVE-2017-15268.patch b/gnu/packages/patches/qemu-CVE-2017-15268.patch
deleted file mode 100644
index 8238c3059f..0000000000
--- a/gnu/packages/patches/qemu-CVE-2017-15268.patch
+++ /dev/null
@@ -1,62 +0,0 @@
-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
-
diff --git a/gnu/packages/virtualization.scm b/gnu/packages/virtualization.scm
index 2f5ad80bc7..a1709b0b6d 100644
--- a/gnu/packages/virtualization.scm
+++ b/gnu/packages/virtualization.scm
@@ -81,19 +81,16 @@
(define-public qemu
(package
(name "qemu")
- (version "2.10.1")
+ (version "2.10.2")
(source (origin
(method url-fetch)
(uri (string-append "https://download.qemu.org/qemu-"
version ".tar.xz"))
(patches (search-patches "qemu-CVE-2017-15038.patch"
- "qemu-CVE-2017-15118.patch"
- "qemu-CVE-2017-15119.patch"
- "qemu-CVE-2017-15268.patch"
"qemu-CVE-2017-15289.patch"))
(sha256
(base32
- "1ahwl7r18iw2ds0q3c51nlivqsan9hcgnc8bbf9pv366iy81mm8x"))))
+ "17w21spvaxaidi2am5lpsln8yjpyp2zi3s3gc6nsxj5arlgamzgw"))))
(build-system gnu-build-system)
(arguments
'(;; Running tests in parallel can occasionally lead to failures, like: