瀏覽代碼

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
Nick Mathewson 7 年之前
父節點
當前提交
9b18b215bb
共有 3 個文件被更改,包括 7 次插入6 次删除
  1. 3 0
      changes/bug20553
  2. 2 3
      src/common/crypto.c
  3. 2 3
      src/tools/tor-gencert.c

+ 3 - 0
changes/bug20553

@@ -0,0 +1,3 @@
+  o Minor bugfixes (memory leak):
+    - Work around a memory leak in OpenSSL 1.1 when encoding public keys.
+      Fixes bug 20553; bugfix on 0.0.2pre8.

+ 2 - 3
src/common/crypto.c

@@ -755,14 +755,13 @@ crypto_pk_write_key_to_string_impl(crypto_pk_t *env, char **dest,
   }
 
   BIO_get_mem_ptr(b, &buf);
-  (void)BIO_set_close(b, BIO_NOCLOSE); /* so BIO_free doesn't free buf */
-  BIO_free(b);
 
   *dest = tor_malloc(buf->length+1);
   memcpy(*dest, buf->data, buf->length);
   (*dest)[buf->length] = 0; /* nul terminate it */
   *len = buf->length;
-  BUF_MEM_free(buf);
+
+  BIO_free(b);
 
   return 0;
 }

+ 2 - 3
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;