summaryrefslogtreecommitdiff
path: root/src/tools
diff options
context:
space:
mode:
authorNick Mathewson <nickm@torproject.org>2016-11-03 10:46:27 -0400
committerNick Mathewson <nickm@torproject.org>2016-11-03 10:51:10 -0400
commit9b18b215bb34c4df1b94dec218c68a532c341e26 (patch)
tree10bd0b176265791a9305283cece3933a87842dca /src/tools
parentb0f1241a1d9319387eb536c1edd0b4c15d1e8ac3 (diff)
downloadtor-9b18b215bb34c4df1b94dec218c68a532c341e26.tar.gz
tor-9b18b215bb34c4df1b94dec218c68a532c341e26.zip
Work around a behavior change in openssl's BUF_MEM code
In our code to write public keys to a string, for some unfathomable reason since 253f0f160e1185c, we would allocate a memory BIO, then set the NOCLOSE flag on it, extract its memory buffer, and free it. Then a little while later we'd free the memory buffer with BUF_MEM_free(). As of openssl 1.1 this doesn't work any more, since there is now a BIO_BUF_MEM structure that wraps the BUF_MEM structure. This BIO_BUF_MEM doesn't get freed in our code. So, we had a memory leak! Is this an openssl bug? Maybe. But our code was already pretty silly. Why mess around with the NOCLOSE flag here when we can just keep the BIO object around until we don't need the buffer any more? Fixes bug 20553; bugfix on 0.0.2pre8
Diffstat (limited to 'src/tools')
-rw-r--r--src/tools/tor-gencert.c5
1 files changed, 2 insertions, 3 deletions
diff --git a/src/tools/tor-gencert.c b/src/tools/tor-gencert.c
index 5f2cd3a92d..ed6c0667a1 100644
--- a/src/tools/tor-gencert.c
+++ b/src/tools/tor-gencert.c
@@ -429,12 +429,11 @@ key_to_string(EVP_PKEY *key)
}
BIO_get_mem_ptr(b, &buf);
- (void) BIO_set_close(b, BIO_NOCLOSE);
- BIO_free(b);
result = tor_malloc(buf->length + 1);
memcpy(result, buf->data, buf->length);
result[buf->length] = 0;
- BUF_MEM_free(buf);
+
+ BIO_free(b);
RSA_free(rsa);
return result;