Re: [openssl-users] Potential memory leak in RSA_private_decrypt

My further investigation showed this is a memory leak in my application code rather than an OpenSSL leak. Thanks, Wang -- Sent from: http://openssl.6102.n7.nabble.com/OpenSSL-User-f3.html -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] Potential memory leak in RSA_private_decrypt

My further investigation showed this is a memory leak in application code, rather than an OpenSSL one. Thanks, Wang -- Sent from: http://openssl.6102.n7.nabble.com/OpenSSL-User-f3.html -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] Potential memory leak in RSA_private_decrypt

This is very important information. Thank you very much, Matt. I will update the code of my product and test if it resolves my issue. If it does, I will post my feedback here. Hence other users can aviod the same issue. My product is complex and I have other things to do, so it may take a few

Re: [openssl-users] Potential memory leak in RSA_private_decrypt

Thanks again, Rich. >>>There is something strange with the RSA private key or it’s BN_CONT object. >>>Are you sure that you are properly releasing all OpenSSL objecdts in your code? My application is a server. When it is initialized it calls RSA_new() to allocate a RSA object. When the

Re: [openssl-users] Potential memory leak in RSA_private_decrypt

On 08/11/17 09:47, Wang wrote: > Hello Matt, > > Thank you for trying to help. > Is this the "bottom" of the OpenSSL stack? i.e. your application calls RSA_private_decrypt() directly? > Yes, it does. > Do you share a single RSA object across multiple threads? > Yes, my

Re: [openssl-users] Potential memory leak in RSA_private_decrypt

Hello Matt, Thank you for trying to help. >>>Is this the "bottom" of the OpenSSL stack? i.e. your application calls >>>RSA_private_decrypt() directly? Yes, it does. >>>Do you share a single RSA object across multiple threads? Yes, my application shares a single RSA object across many

Re: [openssl-users] Potential memory leak in RSA_private_decrypt

There is something strange with the RSA private key or it’s BN_CONT object. Are you sure that you are properly releasing all OpenSSL objecdts in your code? -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] Potential memory leak in RSA_private_decrypt

On 07/11/17 10:01, Wang wrote: > Hello Rich, > > Thank you for trying to help. > > My product is running on Linux. The following leak was detected by Valgrind. > Valgrind only reportes > the leak in threaded mode. I run 'top' on linux to monitor the memory usage > of my product. I can see the

Re: [openssl-users] Potential memory leak in RSA_private_decrypt

Hello Rich, Thank you for trying to help. My product is running on Linux. The following leak was detected by Valgrind. Valgrind only reportes the leak in threaded mode. I run 'top' on linux to monitor the memory usage of my product. I can see the memory usage increases quickly. ==9721== 520

Re: [openssl-users] Potential memory leak in RSA_private_decrypt

➢ http://openssl.6102.n7.nabble.com/Memory-issues-with-ssl-handshake-td20851.html#a20854. ➢ Don't understand why this issue is not encountered by other users and why it has not been fixed for so many years. The first part answer the second. It is not encountered by others,

Re: [openssl-users] Potential memory leak in RSA_private_decrypt

The product can be build in threaded or non-threaded mode. The memory leak can be detected only in threaded mode. Hence I think I hit the same issue reported by Thomas in 2012. "One thing I noticed is that all goes well if I cause the code to run sequentially (e.g. cause requests to come one

[openssl-users] Potential memory leak in RSA_private_decrypt

Hello, The memory usage of one of our OpenSSL applications increases quickly.Valgrind detects the only possible leak below. We are using OpenSSL 1.0.2k. ==9721== 520 bytes in 1 blocks are indirectly lost in loss record 1,178 of1,294 ==9721==at 0x4A0817C: malloc (vg_replace_malloc.c:298)