diff options
Diffstat (limited to 'gnu/packages/patches')
| -rw-r--r-- | gnu/packages/patches/qemu-CVE-2017-15118.patch | 58 | ||||
| -rw-r--r-- | gnu/packages/patches/qemu-CVE-2017-15119.patch | 68 |
2 files changed, 126 insertions, 0 deletions
diff --git a/gnu/packages/patches/qemu-CVE-2017-15118.patch b/gnu/packages/patches/qemu-CVE-2017-15118.patch new file mode 100644 index 0000000000..d427317be9 --- /dev/null +++ b/gnu/packages/patches/qemu-CVE-2017-15118.patch @@ -0,0 +1,58 @@ +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 new file mode 100644 index 0000000000..6265ecf8d6 --- /dev/null +++ b/gnu/packages/patches/qemu-CVE-2017-15119.patch @@ -0,0 +1,68 @@ +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 + |