<div dir="ltr"><div><div><div><div><div><div>This is openssl-1.0.1k on Fedora 21 x86_64, but it should not matter, here is a brief analysis:<br><br></div>Consider sv_body() in server.c<br></div><br>2237 con=SSL_new(ctx);<br><br></div>Here a new context is initialized. From ssl_lib.c:295, this also causes the krb context to be initialized via<br><br> 295 s->kssl_ctx = kssl_ctx_new();<br><br></div>So SSL_new basically also allocates memory for con->kssl<br><br></div>Later in sv_body() at line 2252:<br><br>2252 if ((kctx = kssl_ctx_new()) != NULL)<br>2253 {<br>2254 SSL_set0_kssl_ctx(con, kctx);<br><br></div><div>This causes con->kssl_ctx to be rewritten by kctx, in doing so 56 bytes of previously allocated memory is lost<br></div><div>and hence the memory leak for each connection made.<br></div><br></div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Jan 15, 2015 at 6:55 PM, Huzaifa Sidhpurwala via RT <span dir="ltr"><<a href="mailto:rt@openssl.org" target="_blank">rt@openssl.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5">Here is how to test it:<br>
<br>
openssl req -x509 -newkey rsa -keyout localhost.key -out localhost.crt -subj \<br>
/CN=localhost -nodes -batch -sha256<br>
<br>
valgrind --leak-check=full openssl s_server -key localhost.key -cert \<br>
localhost.crt -accept 4433<br>
<br>
./poc.py<br>
<br>
Every run of poc.py causes 56 byte memory leak:<br>
<br>
==11278== HEAP SUMMARY:<br>
==11278== in use at exit: 910,716 bytes in 20,383 blocks<br>
==11278== total heap usage: 37,712 allocs, 17,329 frees, 2,596,814 bytes<br>
allocated<br>
==11278==<br>
==11278== 56 bytes in 1 blocks are definitely lost in loss record 658 of 823<br>
==11278== at 0x4C2745D: malloc (in /usr/lib64/valgrind/vgpreload_memcheck-<br>
amd64-linux.so)<br>
==11278== by 0x5A6AD12: CRYPTO_malloc (mem.c:308)<br>
==11278== by 0x4E81729: kssl_calloc.constprop.0 (kssl.c:790)<br>
==11278== by 0x4E759E9: SSL_new (ssl_lib.c:295)<br>
==11278== by 0x436387: sv_body (s_server.c:2004)<br>
==11278== by 0x44AC30: do_server (s_socket.c:324)<br>
==11278== by 0x439C36: s_server_main (s_server.c:1901)<br>
==11278== by 0x419377: do_cmd (openssl.c:489)<br>
==11278== by 0x41906D: main (openssl.c:381)<br>
==11278==<br>
==11278== LEAK SUMMARY:<br>
==11278== definitely lost: 56 bytes in 1 blocks<br>
==11278== indirectly lost: 0 bytes in 0 blocks<br>
==11278== possibly lost: 0 bytes in 0 blocks<br>
==11278== still reachable: 910,660 bytes in 20,382 blocks<br>
==11278== suppressed: 0 bytes in 0 blocks<br>
==11278== Reachable blocks (those to which a pointer was found) are not shown.<br>
==11278== To see them, rerun with: --leak-check=full --show-leak-kinds=all<br>
==11278==<br>
==11278== For counts of detected and suppressed errors, rerun with: -v<br>
==11278== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 2 from 2)<br>
"""<br>
<br>
<br>
Acknowledgement Text Required: Yes<br>
Community Trackers Required : Yes<br>
Ticket Response Required : Yes<br>
<br>
poc.py is attached<br>
<br>
<br>
<br>
On Thu, Jan 15, 2015 at 3:08 PM, Huzaifa Sidhpurwala via RT <<a href="mailto:rt@openssl.org">rt@openssl.org</a>><br>
wrote:<br>
<br>
> Hi,<br>
><br>
> I found a memory leak in s_server.c. On my x86_64 machine, this leaks 56<br>
> bytes for each connection request.<br>
><br>
> Patch is attached.<br>
><br>
><br>
> _______________________________________________<br>
> openssl-dev mailing list<br>
> To unsubscribe: <a href="https://mta.openssl.org/mailman/listinfo/openssl-dev" target="_blank">https://mta.openssl.org/mailman/listinfo/openssl-dev</a><br>
><br>
><br>
<br>
</div></div><br>_______________________________________________<br>
openssl-dev mailing list<br>
To unsubscribe: <a href="https://mta.openssl.org/mailman/listinfo/openssl-dev" target="_blank">https://mta.openssl.org/mailman/listinfo/openssl-dev</a><br>
<br></blockquote></div><br></div>