Re: [openssl-dev] Memory leak in application when we use ECDH

...@openssl.org] On Behalf Of Matt Caswell Sent: Monday, March 27, 2017 3:04 PM To: openssl-dev@openssl.org Subject: Re: [openssl-dev] Memory leak in application when we use ECDH Hi Darshan The behaviour you are seeing is not particularly surprising and does not indicate a memory leak. s_server

Re: [openssl-dev] Memory leak in application when we use ECDH

Hi Darshan The behaviour you are seeing is not particularly surprising and does not indicate a memory leak. s_server maintains a cache of sessions from previous connections to enable the resumption capability. Since your s_client loop isn't resuming it creates a new session every time (which

Re: [openssl-dev] Memory leak in application when we use ECDH

d, 0.0%wa, 0.0%hi, 0.6%si, 0.0%st darshanmody> Mem: 3924288k total, 3756924k used, 167364k free,75952k buffers darshanmody> Swap: 8388604k total, 998972k used, 7389632k free, 216600k cached darshanmody> darshanmody> PID USER PR NI VIRT RES SHR S %CPU %MEM

Re: [openssl-dev] Memory leak in application when we use ECDH

S 10.3 0.2 0:43.23 openssl Thanks Darshan -Original Message- From: openssl-dev [mailto:openssl-dev-boun...@openssl.org] On Behalf Of Mody, Darshan (Darshan) Sent: Thursday, March 23, 2017 7:40 PM To: openssl-dev@openssl.org Cc: Bahr, William G (Bill) Subject: Re: [openssl-dev] Memo

Re: [openssl-dev] Memory leak in application when we use ECDH

Subject: Re: [openssl-dev] Memory leak in application when we use ECDH I think that Matt is asking for example code that exhibits this leak. You could patch apps/s_server.c with your callback, or ssl/ssltest.c, and give us that patch. The reason is that we can't know what assumptions you're going

Re: [openssl-dev] Memory leak in application when we use ECDH

dy> darshanmody> Thanks darshanmody> Darshan darshanmody> darshanmody> -Original Message- darshanmody> From: openssl-dev [mailto:openssl-dev-boun...@openssl.org] On Behalf Of Matt Caswell darshanmody> Sent: Thursday, March 23, 2017 6:55 PM darshanmody> To: openssl-dev@open

Re: [openssl-dev] Memory leak in application when we use ECDH

] Memory leak in application when we use ECDH On 23/03/17 13:19, Mody, Darshan (Darshan) wrote: > Can you further elaborate? > > What we did is to create a TLS connection and with invalid > certificates from the client and server on verification would reject > the certificate. The ci

Re: [openssl-dev] Memory leak in application when we use ECDH

nt: Thursday, March 23, 2017 4:09 PM To: openssl-dev@openssl.org > Subject: Re: [openssl-dev] Memory leak in application when we use > ECDH > > > > On 23/03/17 10:13, Mody, Darshan (Darshan) wrote: >> Matt, >> >> Even after accounting for the EC_KEY

Re: [openssl-dev] Memory leak in application when we use ECDH

Subject: Re: [openssl-dev] Memory leak in application when we use ECDH On 23/03/17 10:13, Mody, Darshan (Darshan) wrote: > Matt, > > Even after accounting for the EC_KEY we still observe some leak. The > leak started after we started using supporting EC with callback > SSL_set_tm

Re: [openssl-dev] Memory leak in application when we use ECDH

On 23/03/17 10:13, Mody, Darshan (Darshan) wrote: > Matt, > > Even after accounting for the EC_KEY we still observe some leak. The > leak started after we started using supporting EC with callback > SSL_set_tmp_ecdh_callback(). > > The core dump shows the string data of the far-end

Re: [openssl-dev] Memory leak in application when we use ECDH

. Thanks Darshan -Original Message- From: openssl-dev [mailto:openssl-dev-boun...@openssl.org] On Behalf Of Matt Caswell Sent: Thursday, March 23, 2017 3:31 PM To: openssl-dev@openssl.org Subject: Re: [openssl-dev] Memory leak in application when we use ECDH On 23/03/17 04:35, Mody

Re: [openssl-dev] Memory leak in application when we use ECDH

On Behalf Of Matt > Caswell > Sent: Tuesday, March 21, 2017 3:28 PM > To: openssl-dev@openssl.org > Subject: Re: [openssl-dev] Memory leak in application when we use ECDH > > > > On 21/03/17 09:46, Matt Caswell wrote: >> >> There is a potential leak in thi

Re: [openssl-dev] Memory leak in application when we use ECDH

rch 23, 2017 10:06 AM To: openssl-dev@openssl.org Cc: Bahr, William G (Bill) Subject: Re: [openssl-dev] Memory leak in application when we use ECDH Matt, But openssl does not release the memory when it has duplicated the EC Key which comes from the application /* Duplicate the ECDH str

Re: [openssl-dev] Memory leak in application when we use ECDH

essage- From: openssl-dev [mailto:openssl-dev-boun...@openssl.org] On Behalf Of Matt Caswell Sent: Tuesday, March 21, 2017 3:28 PM To: openssl-dev@openssl.org Subject: Re: [openssl-dev] Memory leak in application when we use ECDH On 21/03/17 09:46, Matt Caswell wrote: > > There is

Re: [openssl-dev] Memory leak in application when we use ECDH

On 21/03/17 09:46, Matt Caswell wrote: > > There is a potential leak in this case: > > if (s->s3->tmp.ecdh != NULL) { > SSLerr(SSL_F_SSL3_SEND_SERVER_KEY_EXCHANGE, >ERR_R_INTERNAL_ERROR); > goto err; > } > > But

Re: [openssl-dev] Memory leak in application when we use ECDH

On 15/03/17 05:44, Mody, Darshan (Darshan) wrote: > Hi, > > We have observed memory leak when we register for ECDH > callback(SSL_set_tmp_ecdh_callback). While performing negative testing > with load we find that the applications starts leaking memory. > > Further

Re: [openssl-dev] Memory leak in application when we use ECDH

, Alejandro (Alejandro) Subject: [openssl-dev] Memory leak in application when we use ECDH Hi, We have observed memory leak when we register for ECDH callback(SSL_set_tmp_ecdh_callback). While performing negative testing with load we find that the applications starts leaking memory. Further

[openssl-dev] Memory leak in application when we use ECDH

Hi, We have observed memory leak when we register for ECDH callback(SSL_set_tmp_ecdh_callback). While performing negative testing with load we find that the applications starts leaking memory. Further checking the Openssl implementation in the s3_srvr.c file (openssl version 1.0.2). I find

Re: [openssl-dev] [openssl.org #4704] Memory leak in rsa_new/rsa_free

I think your problem (and the stack overflow) is caused by using "CALLBACK" in the 3 function typedefs. Try using __cdecl instead of CALLBACK. __Martin > On Tue, 11 Oct 2016 16:15:24 +, Simone Sgualdini via RT said: > > > Hi, > > > I'm writing a c++ server application that calls

[openssl-dev] [openssl.org #4704] Memory leak in rsa_new/rsa_free

Hi, I'm writing a c++ server application that calls thounsands of times per hour the rsa_new() and rsa_free() openssl functions. After debugging a lot I discovered that "sometimes" (I'm not able to tell a precise number) the rsa_free does not release properly the memory allocated by the

[openssl-dev] [openssl.org #4259] Bug: Apparent memory leak in kssl.c

Seems to have been fixed some time ago. thanks. -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4259 Please log in as guest with password guest if prompted -- openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] [openssl.org #4466] Memory leak in PKCS12_newpass function

Thank you very much for the fix. Best regards, Ramunas > On May 7, 2016, at 12:07 AM, Stephen Henson via RT wrote: > > Fixed, thanks for the report. > > Steve. > -- > Dr Stephen N. Henson. OpenSSL project core developer. > Commercial tech support now available see:

[openssl-dev] [openssl.org #4400] [PATCH] plug potential memory leak in OpenSSL 1.1 pre 4

This patch doesn't look correct. I don't see a memory leak here. Closing. Matt -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4400 Please log in as guest with password guest if prompted -- openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl

[openssl-dev] [openssl.org #4466] Memory leak in PKCS12_newpass function

Fixed, thanks for the report. Steve. -- Dr Stephen N. Henson. OpenSSL project core developer. Commercial tech support now available see: http://www.openssl.org -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4466 Please log in as guest with password guest if prompted --

[openssl-dev] [openssl.org #4466] Memory leak in PKCS12_newpass function

On Mon Mar 21 13:02:56 2016, ramunas.jurgi...@gmail.com wrote: > I did write function which changes PKCS12 passphrase. I noticed that > PKCS12_newpass function leaks memory. Memory leak disappears when > commenting out line where is PKCS12_newpass func. > > Below I posted this

[openssl-dev] [openssl.org #4433] Memory leak in X509_REQ_to_X509

X509_REQ_to_X509 returns a newly allocated X509 structure. If you believe that it leaks somewhere else, then please reopen this ticket with fully self-contained code, and a trace (e.g., from valgrind) showing where the leak happens. Emilia -- Ticket here:

[openssl-dev] [openssl.org #4465] PKCS12_newpass memory leak

I did write function which changes PKCS12 passphrase. I noticed that PKCS12_newpass function leaks memory. Memory leak disappears when commenting out line where is PKCS12_newpass func. Below I posted this code which I am using. I am using OpneSSL 1.0.2g version. Could you please give me

[openssl-dev] [openssl.org #4466] Memory leak in PKCS12_newpass function

I did write function which changes PKCS12 passphrase. I noticed that PKCS12_newpass function leaks memory. Memory leak disappears when commenting out line where is PKCS12_newpass func. Below I posted this code which I am using. I am using OpneSSL 1.0.2g version. Could you please give me

[openssl-dev] Memory leak in PKCS12_newpass function

Hello OpenSSL Team, I did write function which changes PKCS12 passphrase. I noticed that PKCS12_newpass function leaks memory. Memory leak disappears when commenting out line where is PKCS12_newpass func. Below I posted this code which I am using. I am using OpneSSL 1.0.2g version. Could you

[openssl-dev] [openssl.org #4433] Memory leak in X509_REQ_to_X509

Hello OpenSSL Team, During memory leak hunting on iOS platform I noticed, that function X509_REQ_to_X509 generates memory. Bellow you can found code snapshot. As well I would like to know do you plan to fix this memory leak? If yes, then when? Best regards, Ramunas X509_REQ *req = NULL

[openssl-dev] [openssl.org #4220] Simple BIO demo make memory leak

In 1.1 you don't need to do anything, openssl will free its internal resources. before 1.1 you have to call various free/release routines to remove internal state. see what is done in the apps, for example. closing this ticket. -- Rich Salz, OpenSSL dev team; rs...@openssl.org -- Ticket here:

[openssl-dev] [openssl.org #4401] [PATCH] plug potential memory leak(s) in OpenSSL 1.1 pre 4 in 'ec_lib.c'

Yep, there is no need to clean up early here (we don't guarantee that errored calls leave everything in a pristine unmodified state). Plus this does indeed forget to zero the pointer. Closing. Thanks for submitting, though, and thanks David for the review! -- Ticket here:

Re: [openssl-dev] [openssl.org #4401] [PATCH] plug potential memory leak(s) in OpenSSL 1.1 pre 4 in 'ec_lib.c'

By the way, returning the original subject, I don't believe there is a leak here. If EC_GROUP_copy fails, dest still exists and is owned by the caller. It's the caller's obligation to call EC_GROUP_free and that will release the partially-copied EC_GROUP. (Which will, with this patch, cause a

Re: [openssl-dev] [openssl.org #4401] [PATCH] plug potential memory leak(s) in OpenSSL 1.1 pre 4 in 'ec_lib.c'

Geez, What did I start here (egad) :) Bill On Wed, Mar 9, 2016 at 5:03 AM, Salz, Rich via RT wrote: > > No, you got that right, NULL being 'safe' to free varies with OS. > > Except we mandate ANSI C which means it's portable :) > > -- > Ticket here:

Re: [openssl-dev] [openssl.org #4401] [PATCH] plug potential memory leak(s) in OpenSSL 1.1 pre 4 in 'ec_lib.c'

> No, you got that right, NULL being 'safe' to free varies with OS. Except we mandate ANSI C which means it's portable :) -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4401 Please log in as guest with password guest if prompted -- openssl-dev mailing list To unsubscribe:

Re: [openssl-dev] [openssl.org #4401] [PATCH] plug potential memory leak(s) in OpenSSL 1.1 pre 4 in 'ec_lib.c'

On 9 March 2016 at 05:30, Peter Waltenberg wrote: > No, you got that right, NULL being 'safe' to free varies with OS. > > ​It shouldn't if you're programming in C, from the standard (C89): The free function causes the space pointed to by ptr to be deallocated, that is, made

Re: [openssl-dev] [openssl.org #4401] [PATCH] plug potential memory leak(s) in OpenSSL 1.1 pre 4 in 'ec_lib.c'

On 9 March 2016 at 05:30, Peter Waltenberg wrote: > No, you got that right, NULL being 'safe' to free varies with OS. > > ​It shouldn't if you're programming in C, from the standard (C89): The free function causes the space pointed to by ptr to be deallocated, that is, made

Re: [openssl-dev] [openssl.org #4401] [PATCH] plug potential memory leak(s) in OpenSSL 1.1 pre 4 in 'ec_lib.c'

er via RT Sent by: "openssl-dev" Date: 03/09/2016 07:53AM Cc: openssl-dev@openssl.org Subject: Re: [openssl-dev] [openssl.org #4401] [PATCH] plug potential memory leak(s) in OpenSSL 1.1 pre 4 in 'ec_lib.c' I must be brain dead today, since free'ing something that is already NULL is not a p

Re: [openssl-dev] [openssl.org #4401] [PATCH] plug potential memory leak(s) in OpenSSL 1.1 pre 4 in 'ec_lib.c'

--From: Bill Parker via RT <r...@openssl.org>Sent by: "openssl-dev" <openssl-dev-boun...@openssl.org>Date: 03/09/2016 07:53AMCc: openssl-dev@openssl.orgSubject: Re: [openssl-dev] [openssl.org #4401] [PATCH] plug potential memoryleak(s) in OpenSSL 1.1 pre 4

Re: [openssl-dev] [openssl.org #4401] [PATCH] plug potential memory leak(s) in OpenSSL 1.1 pre 4 in 'ec_lib.c'

I must be brain dead today, since free'ing something that is already NULL is not a problem (geez)... Heh On Tue, Mar 8, 2016 at 12:01 PM, Salz, Rich via RT wrote: > > > + if (dest->mont_data != NULL) > > + BN_MONT_CTX_free(dest->mont_data); > >

Re: [openssl-dev] [openssl.org #4401] [PATCH] plug potential memory leak(s) in OpenSSL 1.1 pre 4 in 'ec_lib.c'

> >> + if (dest->mont_data != NULL) > >> + BN_MONT_CTX_free(dest->mont_data); > > > >Free routines don't need to check for non-NULL. > > Yes, don’t *have* to. But does it hurt to check? It makes folks wonder why the check is only there sometimes. It adds to code

Re: [openssl-dev] [openssl.org #4401] [PATCH] plug potential memory leak(s) in OpenSSL 1.1 pre 4 in 'ec_lib.c'

On 3/8/16, 15:01 , "openssl-dev on behalf of Salz, Rich via RT" wrote: > >> + if (dest->mont_data != NULL) >> + BN_MONT_CTX_free(dest->mont_data); > >Free routines don't need to check for non-NULL.

Re: [openssl-dev] [openssl.org #4401] [PATCH] plug potential memory leak(s) in OpenSSL 1.1 pre 4 in 'ec_lib.c'

> + if (dest->mont_data != NULL) > + BN_MONT_CTX_free(dest->mont_data); Free routines don't need to check for non-NULL. -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4401 Please log in as guest with password guest if prompted -- openssl-dev

[openssl-dev] [openssl.org #4401] [PATCH] plug potential memory leak(s) in OpenSSL 1.1 pre 4 in 'ec_lib.c'

Hello All, In reviewing code in directory 'crypto/ec', file 'ec_lib.c'', there appears to be allocated memory which is not released when a return 0; is encountered in some cases of OPENSSL_malloc(). The patch file below should address/correct these minor leaks: --- ec_lib.c.orig

[openssl-dev] [openssl.org #4400] [PATCH] plug potential memory leak in OpenSSL 1.1 pre 4

Hello All, In reviewing source code in directory 'crypto/ocsp', file 'ocsp_ht.c', there is a minor flaw in the test logic which could allow a small memory leak to develop. The patch file below should address/correct this issue: --- ocsp_ht.c.orig 2016-03-08 10:24:51.821632969 -0800

[openssl-dev] [openssl.org #2439] bug report: memory leak

In our review, the code is correct and there is no leak. Please provide a patch against the current release if you think otherwise. -- Rich Salz, OpenSSL dev team; rs...@openssl.org -

[openssl-dev] [openssl.org #2536] Memory leak in d2i_RSA_PUBKEY() (concise test code included)

The d2i routines move the pointer to the next thing. So you have do save key, pass in a copy, and then delete the original key. -- Rich Salz, OpenSSL dev team; rs...@openssl.org -

[openssl-dev] [openssl.org #2673] Bug report: OpenSSL Memory leak in B64 encode

An OpenSSL cleanup call (such as clean_ex_data) must be called before existing, else internal data will be kept around. Closing ticket. -- Rich Salz, OpenSSL dev team; rs...@openssl.org ___ openssl-dev mailing list To unsubscribe:

[openssl-dev] [openssl.org #3640] Bug report: PKCS7_decrypt memory leak

No reply, cannot reproduce the bug, closing the ticket. -- Rich Salz, OpenSSL dev team; rs...@openssl.org ___ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

[openssl-dev] [openssl.org #1802] Bug report: Persistent memory leak that cannot be freed

This is reported against 0.9.8; please open a new ticket if still a problem with current releases. -- Rich Salz, OpenSSL dev team; rs...@openssl.org ___ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] "openssl s_client" memory leak

Thanks for looking into this. I don't think it's gonna be on anyone's high priority list to fix in the next release, so feel free to keep at it :) ___ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

[openssl-dev] [openssl.org #4259] Bug: Apparent memory leak in kssl.c

Hello - I ran OpenSSL v1.0.2e through static analysis (Cppcheck v1.62) and there was one apparent memory leak identified as follows: openssl-1.0.2e\ssl\kssl.c error line: 2234 Memory leak: p_data (new_p is freed in the error return condition, but its data field references a buffer

[openssl-dev] "openssl s_client" memory leak

There seems to be some memory leak(s) somewhere during the life of 's_client_main()'. Example from a client.bat here: set OPENSSL_DEBUG_MEMORY=on echo -e GET /ssltest/viewMyClient.html\r\n | openssl.exe s_client ^ -connect www.ssllabs.com:443 ('echo -e' is from Cygwin32). All

[openssl-dev] [openssl.org #4220] Simple BIO demo make memory leak

Dear, Recently, I got an issue on my RHEL6.5 x64 platform with original openssl-1.0.2e without patch. Please find the attached files for testing demo, this simple demo will generate Memory Leak, is it a bug ? I am not sure why? Thank you for in advance. The same test on Win7 x64

[openssl-dev] [openssl.org #4197] [PATCH] Memory leak in state machine in error path

On Tue Dec 22 17:02:07 2015, tsh...@akamai.com wrote: > Hello OpenSSL org: > > I found the following issue via code inspection. In > tls_process_client_key_exchange(), when EC is disabled, and an error > occurs in ssl_generate_master_secret() or RAND_bytes(), the error path > does not free

Re: [openssl-dev] [openssl.org #4184] Memory leak in DSA redo case

Fixed. Kurt ___ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

[openssl-dev] [openssl.org #4197] [PATCH] Memory leak in state machine in error path

by OPENSSL_NO_RSA, so I did not wrap the free with that conditional. -- -Todd Short // tsh...@akamai.com<mailto:tsh...@akamai.com> // "One if by land, two if by sea, three if by the Internet." 0001-Memory-leak-in-state-machine-in-error-path.patch Descript

[openssl-dev] memory leak?

This looks like a potential memory leak to me... openssl-1.0.2e/crypto/x509/x509_lu.c: X509_STORE *X509_STORE_new(void) { X509_STORE *ret; if ((ret = (X509_STORE *)OPENSSL_malloc(sizeof(X509_STORE))) == NULL) return NULL; ret->objs = sk_X509_OBJECT_new(x509_object_

[openssl-dev] [openssl.org #4184] Memory leak in DSA redo case

dsa_do_sign retries the operation if |r| or |s| end up zero. This results in leaking the first iteration's value of |ret| since you end up clobbering the previous allocation.

[openssl-dev] [openssl.org #4131] Memory leak when parsing invalid X509_ATTRIBUTE

Assigned CVE-2015-3195 and fixed now. Thanks for the report. Steve. -- Dr Stephen N. Henson. OpenSSL project core developer. Commercial tech support now available see: http://www.openssl.org ___ openssl-dev mailing list To unsubscribe:

Re: [openssl-dev] Openssl Memory Leak

Ø Can anyone let us know about the leaks and will SSL_FREE() will free the above memory. It should. Try it. ___ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] [openssl.org #4131] AutoReply: Memory leak when parsing invalid X509_ATTRIBUTE

(Please note that credit for this goes to libFuzzer.) ___ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

[openssl-dev] [openssl.org #4134] [BUG] Memory leak in STORE_store_private_key()

Hello! I work with openssl 1.0.2d, and I found a memory leak in STORE_store_private_key() function (defined in crypto/store/str_lib.c). Here is a code fragment: 465:int STORE_store_private_key(STORE *s, EVP_PKEY *data, 466:OPENSSL_ITEM attributes[], 467

[openssl-dev] [openssl.org #4134] [BUG] Memory leak in STORE_store_private_key()

t; > I work with openssl 1.0.2d, and I found a memory leak in > STORE_store_private_key() function (defined in crypto/store/str_lib.c). > Here is a code fragment: > > 465:int STORE_store_private_key(STORE *s, EVP_PKEY *data, > 466: OPENSSL_ITEM attributes[], > 467: OPENSSL_ITEM

[openssl-dev] [openssl.org #4131] Memory leak when parsing invalid X509_ATTRIBUTE

The following code: EVP_PKEY_free(d2i_AutoPrivateKey(NULL, , n)); Will leak memory when fed this input:

[openssl-dev] Openssl Memory Leak

Hai All, We are hitting at critical Memory leaks in ssl3_get_client_certificate() where are not able to run calls in load. The backtrace of the leak is 291 bytes in 97 blocks are indirectly lost in loss record 2,354 of 3,052 ==31717==at 0x4C28BED: malloc (in

Re: [openssl-dev] [openssl.org #4103] Valgrind reported memory leak in X509_PUBKEY_get

Please ignore this. Issue found in user code. Thank you so much. On Thu, Oct 22, 2015 at 12:18 AM, Salz, Rich via RT wrote: > > I am trying figure out valgrind report leak. in openssl 1.0.1c. > > You don't have enough of the backtrace for us to reproduce it. Please add > a

[openssl-dev] [openssl.org #4103] Valgrind reported memory leak in X509_PUBKEY_get

closing per request of submittor. -- Rich Salz, OpenSSL dev team; rs...@openssl.org ___ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

[openssl-dev] [openssl.org #4103] Valgrind reported memory leak in X509_PUBKEY_get

Hi, I am trying figure out valgrind report leak. in openssl 1.0.1c. Can any one comment if this already fixed and what is the fix. ==30824== 912 (56 direct, 856 indirect) bytes in 1 blocks are definitely lost in loss record 837 of 907 ==30824==at 0x4A07F9E: malloc (vg_replace_malloc.c:291)

Re: [openssl-dev] [openssl.org #4103] Valgrind reported memory leak in X509_PUBKEY_get

> I am trying figure out valgrind report leak. in openssl 1.0.1c. You don't have enough of the backtrace for us to reproduce it. Please add a simple demo program. ___ openssl-dev mailing list To unsubscribe:

[openssl-dev] [openssl.org #4092] Fwd: Memory Leak in X509_STORE_CTX_init

Hi, Valgrind Reported Leak = ==16773== 56 bytes in 1 blocks are definitely lost in loss record 806 of 1,182 ==16773==at 0x4A07F9E: malloc (vg_replace_malloc.c:291) ==16773==by 0x3613672AE7: CRYPTO_malloc (in /lib64/libcrypto.so.1.0.0) ==16773==by

[openssl-dev] [openssl.org #4031] memory leak in crypto/asn1/x_x509a.c

create by mistake. -- Rich Salz, OpenSSL dev team; rs...@openssl.org ___ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

[openssl-dev] [openssl.org #1543] memory leak in crypto/asn1/x_x509a.c

yes, it looks like these have been fixed. -- Rich Salz, OpenSSL dev team; rs...@openssl.org ___ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] [openssl.org #1543] memory leak in crypto/asn1/x_x509a.c

Same as #1542, the patch is mangled but I think everything is already fixed so this can be closed. Cheers ___ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] [openssl.org #4031] Re: [openssl-dev #1543] memory leak in crypto/asn1/x_x509a.c

On Sat, Sep 05, 2015 at 01:49:52pm +, Alessandro Ghedini via RT wrote: > Same as #1542, the patch is mangled but I think everything is already fixed so > this can be closed. Same as #4031. It was supposed to be a reply to #1543 and can be closed. Cheers

[openssl-dev] [openssl.org #4031] Re: [openssl-dev #1543] memory leak in crypto/asn1/x_x509a.c

Same as #1542, the patch is mangled but I think everything is already fixed so this can be closed. Cheers ___ openssl-bugs-mod mailing list openssl-bugs-...@openssl.org https://mta.openssl.org/mailman/listinfo/openssl-bugs-mod

[openssl-dev] [openssl.org #3917] Bug report -- potential memory leak

OpenSSL_1_0_2-stable 4475451 RT3917: add cleanup on an error path master 7fba840 RT3917: add cleanup on an error path Author: Rich Salz rs...@akamai.com Date: Sun Jun 21 15:37:53 2015 -0400 RT3917: add cleanup on an error path Reviewed-by: Richard Levitte levi...@openssl.org -- Rich Salz,

[openssl-dev] [openssl.org #3917] Bug report -- potential memory leak

Hi, affects all systems, happens at least in OpenSSL 1.0.2c. In `crypto/cms/cms_smime.c`, the function `CMS_verify` will leak memory pointed to by `cms_certs` and `crls` variables if the call to `BIO_new_mem_buf` on line 374 fails. Thanks, -- Martin

[openssl-dev] [openssl.org #3848] [PATCH] Fix memory leak caused by not calling SSL_COMP_free_compression_methods()

Thanks! Applied. commit 45d051c82563a75b07ec54b63e3a5bbad388ab67 Author: Gunnar Kudrjavets gunna...@exchange.microsoft.com Date: Wed May 13 15:13:55 2015 -0400 RT3848: Call SSL_COMP_free_compression_methods Signed-off-by: Rich Salz rs...@akamai.com Reviewed-by: Matt Caswell m...@openssl.org --

[openssl-dev] [openssl.org #3861] [patch] Fix memory leak in req

The code in apps/req.c will use the variable out for both the key and the csr outfile. This causes a memory leak because if both a private key and a csr is written the variable is re-used without freeing it. See attached patch. (This could also be fixed by using a different var for both files

[openssl-dev] [openssl.org #3861] [patch] Fix memory leak in req

commit cf89a80e25b79ae0e6004e4a2509bf656fb59168 Author: Hanno BC3B6ck ha...@hboeck.de Date: Mon May 25 16:18:07 2015 -0400 RT3861: Mem/bio leak in req command The out variable is used for both key and csr. Close it after writing the first one so it can be re-used when writing the other.

[openssl-dev] [openssl.org #3848] [PATCH] Fix memory leak caused by not calling SSL_COMP_free_compression_methods()

Hello, Currently 'apps_shutdown()' in 'openssl.c' isn't freeing the compression methods. This is causing the CRT debug heap (and I assume various other tools) to indicate a memory leak. Though OS will free all the resources when user-mode application exits, it's better to do this explicitly

[openssl-dev] [openssl.org #2561] Memory leak with SSL built-in compressions

fixed by steve H. See also ticket 1207, which will be closed when we update the docs. -- Rich Salz, OpenSSL dev team; rs...@openssl.org ___ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

[openssl-dev] [openssl.org #1714] DTLS: Memory leak when server receives close alert from unknown peer

This was fixed some while ago. Closing ticket. Matt ___ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

[openssl-dev] [openssl.org #3662] [bug report]DTLS memory leak in dtls1_accept when use PSK in opensll 1.0.1j

Please see: https://www.openssl.org/support/faq.html#PROG13 Also see RT ticket 3824. Closing this ticket as 3824 seems the better place to track this issue. Matt ___ openssl-dev mailing list To unsubscribe:

[openssl-dev] [openssl.org #2561] Memory leak with SSL built-in compressions

On Wed Apr 29 00:34:11 2015, noloa...@gmail.com wrote: Is there any progress on this? See SSL_COMP_free_compression_methods(). Steve. -- Dr Stephen N. Henson. OpenSSL project core developer. Commercial tech support now available see: http://www.openssl.org

[openssl-dev] [openssl.org #2561] Re: Memory leak with SSL built-in compressions

://openssl.6102.n7.nabble.com/Small-memory-leak-on-multithreaded-server-td54921.html I know some others disagree, but that's really just bike shedding (http://bikeshed.com/).If one person feels its OK to leak memory, then that's fine. But everyone else should not be made to suffer the other's

[openssl-dev] [openssl.org #3658] Memory leak in dtls1_send_server_certificate dtls1_buffer_message

Off list discussions have identified that this issue was due to user code incorrectly re-calling DTLSv1_listen after it has already successfully returned. Therefore closing this issue. Matt ___ openssl-dev mailing list To unsubscribe:

[openssl-dev] [openssl.org #3640] Bug report: PKCS7_decrypt memory leak

On Tue Dec 23 09:14:09 2014, luis.gar...@csr.com wrote: When using PKCS7_decrypt with the following parameters: BIO *bio = BIO_new(BIOS_s_mem()); PKCS7 pointer, EVP_PKEY pointer, X509 pointer, bio, 0. I am getting a memory leak of 568 bytes. Can you post a sample program? Or perhaps some

[openssl-dev] [openssl.org #3679] Memory leak in ssl_cert_dup (ssl/ssl_cert.c)

Hello, Our UC-KLEE tool found a memory leak in ssl_cert_dup (ssl/ssl_cert.c). The bug affects commit 43257b9f51de749262258668c77c2f0f99d7a15b from the 1.0.2 branch, but it appears to date back many years. On line 222 of ssl/ssl_cert.c, ssl_cert_dup() allocates a new CERT: ret = (CERT

[openssl-dev] [openssl.org #1353] memory leak in EVP sign and verification functions

demo was probably7 fixed with these commits: commit 89f534e1d30ed40a03455b36cda7da13734e7238 Author: Dr. Stephen Henson st...@openssl.org Date: Fri Sep 28 00:47:36 2001 + Make (ancient) sign.c demo compile again. commit 5f6d0ea21050fd8a801c6681002e76689a5993b6 Author: Dr. Stephen Henson

[openssl-dev] [openssl.org #1353] memory leak in EVP sign and verification functions

demo was probably7 fixed with these commits: commit 89f534e1d30ed40a03455b36cda7da13734e7238 Author: Dr. Stephen Henson st...@openssl.org Date: Fri Sep 28 00:47:36 2001 + Make (ancient) sign.c demo compile again. commit 5f6d0ea21050fd8a801c6681002e76689a5993b6 Author: Dr. Stephen Henson

Re: [openssl-dev] [openssl.org #3660] Memory leak in s_server.c

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

[openssl-dev] [openssl.org #3660] Memory leak in s_server.c

On Thu Jan 15 10:38:58 2015, sidhpurwala.huza...@gmail.com 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. I'm not seeing this memory leak. The kctx object should be being freed in the call to SSL_free

[openssl-dev] [openssl.org #3660] Memory leak in s_server.c

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. patch Description: Binary data ___ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo

[openssl-dev] [openssl.org #3658] Memory leak in dtls1_send_server_certificate dtls1_buffer_message

Seeing the memory leak (process DTLS server) in the latest released 1.01k version on the server side. Any clue as to how to get this fixed? Regards -Praveen Kariyanahalli ==1162== 36,480 (1,920 direct, 34,560 indirect) bytes in 30 blocks are definitely lost in loss record 119 of 130 ==1162

Re: [openssl-dev] [openssl.org #3660] Memory leak in s_server.c

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

Re: [openssl-dev] [openssl.org #3660] Memory leak in s_server.c

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

[openssl-dev] [openssl.org #3660] Memory leak in s_server.c

-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

Re: [openssl-dev] [openssl.org #3660] Memory leak in s_server.c

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

  1   2   3   >