[OE-core] [ROCKO][PATCH V3 17/34] qemu: CVE-2017-15119

Jagadeesh Krishnanjanappa jkrishnanjanappa at mvista.com
Wed Aug 22 15:08:35 UTC 2018


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.

Affects qemu < 2.11

Signed-off-by: Jagadeesh Krishnanjanappa <jkrishnanjanappa at mvista.com>
---
 .../qemu/qemu/CVE-2017-15119.patch                 | 63 ++++++++++++++++++++++
 meta/recipes-devtools/qemu/qemu_2.10.0.bb          |  1 +
 2 files changed, 64 insertions(+)
 create mode 100644 meta/recipes-devtools/qemu/qemu/CVE-2017-15119.patch

diff --git a/meta/recipes-devtools/qemu/qemu/CVE-2017-15119.patch b/meta/recipes-devtools/qemu/qemu/CVE-2017-15119.patch
new file mode 100644
index 0000000..10da519
--- /dev/null
+++ b/meta/recipes-devtools/qemu/qemu/CVE-2017-15119.patch
@@ -0,0 +1,63 @@
+From fdad35ef6c5839d50dfc14073364ac893afebc30 Mon Sep 17 00:00:00 2001
+From: Eric Blake <eblake at 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 at nongnu.org
+CVE: CVE-2017-15119
+Upstream-Status: Backport [https://git.qemu.org/?p=qemu.git;a=commit;h=fdad35ef6c5839d50dfc14073364ac893afebc30]
+
+Signed-off-by: Eric Blake <eblake at redhat.com>
+Signed-off-by: Jagadeesh Krishnanjanappa <jkrishnanjanappa at mvista.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.13.3
+
diff --git a/meta/recipes-devtools/qemu/qemu_2.10.0.bb b/meta/recipes-devtools/qemu/qemu_2.10.0.bb
index 89c68f2..a3cfb7c 100644
--- a/meta/recipes-devtools/qemu/qemu_2.10.0.bb
+++ b/meta/recipes-devtools/qemu/qemu_2.10.0.bb
@@ -31,6 +31,7 @@ SRC_URI = "http://wiki.qemu-project.org/download/${BP}.tar.bz2 \
            file://ppc_locking.patch \
            file://memfd.patch \
            file://0001-CVE-2018-11806-QEMU-slirp-heap-buffer-overflow.patch \
+           file://CVE-2017-15119.patch \
            "
 UPSTREAM_CHECK_REGEX = "qemu-(?P<pver>\d+\..*)\.tar"
 
-- 
2.7.4




More information about the Openembedded-core mailing list