diff options
Diffstat (limited to 'gnu/packages/patches/qemu-CVE-2017-15119.patch')
| -rw-r--r-- | gnu/packages/patches/qemu-CVE-2017-15119.patch | 68 |
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 - |