* gnu/packages/patches/qemu-CVE-2017-15118.patch, gnu/packages/patches/qemu-CVE-2017-15119.patch: New files. * gnu/local.mk (dist_patch_DATA): Add them. * gnu/packages/virtualization.scm (qemu)[source]: Use them.
		
			
				
	
	
		
			68 lines
		
	
	
	
		
			2.6 KiB
		
	
	
	
		
			Diff
		
	
	
	
	
	
			
		
		
	
	
			68 lines
		
	
	
	
		
			2.6 KiB
		
	
	
	
		
			Diff
		
	
	
	
	
	
| 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
 | |
| 
 |