From 0ce164b7410c1c4a75eefaef48896ee245eeba5c Mon Sep 17 00:00:00 2001

From: Eric Blake <eblake@redhat.com>

Date: Wed, 13 Dec 2017 18:17:29 +0100

Subject: [PATCH 4/6] nbd/server: CVE-2017-15119 Reject options larger than 32M

RH-Author: Eric Blake <eblake@redhat.com>

Message-id: <20171213181730.1278-2-eblake@redhat.com>

Patchwork-id: 78394

O-Subject: [RHEV-7.5 qemu-kvm-rhev PATCH 1/2] nbd/server: CVE-2017-15119 Reject options larger than 32M

Bugzilla: 1518529 1518551

CVE: CVE-2017-15119/20171128

RH-Acked-by: Dr. David Alan Gilbert <dgilbert@redhat.com>

RH-Acked-by: John Snow <jsnow@redhat.com>

RH-Acked-by: Stefan Hajnoczi <stefanha@redhat.com>

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>

(cherry picked from commit fdad35ef6c5839d50dfc14073364ac893afebc30)

Signed-off-by: Miroslav Rezanina <mrezanin@redhat.com>

---

 nbd/server.c | 6 ++++++

 1 file changed, 6 insertions(+)

diff --git a/nbd/server.c b/nbd/server.c

index 993ade3..b93cb88 100644

--- a/nbd/server.c

+++ b/nbd/server.c

@@ -661,6 +661,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 &&

-- 

1.8.3.1