mirror of
https://git.in.rschanz.org/ryan77627/guix.git
synced 2024-12-25 22:08:16 -05:00
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.
This commit is contained in:
parent
2ea3333504
commit
937790df9d
5 changed files with 2 additions and 196 deletions
|
@ -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 \
|
||||
|
|
|
@ -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
|
||||
|
|
@ -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
|
||||
|
|
@ -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
|
||||
|
|
@ -81,19 +81,16 @@ (define (qemu-patch commit file-name sha256)
|
|||
(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:
|
||||
|
|
Loading…
Reference in a new issue