summaryrefslogtreecommitdiffstats
diff options
context:
space:
mode:
authorMatt Caswell <matt@openssl.org>2016-09-09 10:53:39 +0100
committerMatt Caswell <matt@openssl.org>2016-09-22 09:28:07 +0100
commit6d32c2ae28952b5c1d7a24968e488532fcadc51a (patch)
treeeeae76c033d526b3d05415d9ce441eb9ec721eb1
parentf6a7505e64d06f9d41e01b763b684e4e2df34922 (diff)
Fix a mem leak in NPN handling
If a server sent multiple NPN extensions in a single ClientHello then a mem leak can occur. This will only happen where the client has requested NPN in the first place. It does not occur during renegotiation. Therefore the maximum that could be leaked in a single connection with a malicious server is 64k (the maximum size of the ServerHello extensions section). As this is client side, only occurs if NPN has been requested and does not occur during renegotiation this is unlikely to be exploitable. Issue reported by Shi Lei. Reviewed-by: Rich Salz <rsalz@openssl.org>
-rw-r--r--ssl/t1_lib.c5
1 files changed, 5 insertions, 0 deletions
diff --git a/ssl/t1_lib.c b/ssl/t1_lib.c
index 8c0a20f963..86833d8c98 100644
--- a/ssl/t1_lib.c
+++ b/ssl/t1_lib.c
@@ -2405,6 +2405,11 @@ static int ssl_scan_serverhello_tlsext(SSL *s, PACKET *pkt, int *al)
*al = TLS1_AD_INTERNAL_ERROR;
return 0;
}
+ /*
+ * Could be non-NULL if server has sent multiple NPN extensions in
+ * a single Serverhello
+ */
+ OPENSSL_free(s->next_proto_negotiated);
s->next_proto_negotiated = OPENSSL_malloc(selected_len);
if (s->next_proto_negotiated == NULL) {
*al = TLS1_AD_INTERNAL_ERROR;