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.

1 files changed, 0 insertions, 68 deletions

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
-