me
/
guix
Archived
1
0
Fork 0

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.
master
Marius Bakke 2017-12-19 01:15:09 +01:00
parent 2ea3333504
commit 937790df9d
No known key found for this signature in database
GPG Key ID: A2A06DF2A33A54FA
5 changed files with 2 additions and 196 deletions

View File

@ -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 \

View File

@ -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

View File

@ -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

View File

@ -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

View File

@ -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: