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