[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Memory leak in _gnutls_mpi_dprint_lz (possibly _gnutls_mpi_dprint)

From: Sam Varshavchik
Subject: Re: Memory leak in _gnutls_mpi_dprint_lz (possibly _gnutls_mpi_dprint)
Date: Sun, 29 Jun 2008 09:17:24 -0400

Nikos Mavrogiannopoulos writes:

Sam Varshavchik wrote:

I'm chasing a complaint from valgrind that I'm leaking memory.
Here's valgrind's complaint:

==26738== 257 bytes in 1 blocks are definitely lost in loss record 2 of 4
==26738==    at 0x4A0739E: malloc (vg_replace_malloc.c:207)
==26738==    by 0x35068328F6: _gnutls_mpi_dprint_lz (gnutls_mpi.c:146)
==26738==    by 0x350683E47C: _gnutls_dh_set_peer_public
==26738==    by 0x3506843819: _gnutls_proc_dh_common_server_kx
==26738==    by 0x350683BB4F: proc_dhe_server_kx (auth_dhe.c:199)
==26738==    by 0x350682AF81: _gnutls_recv_server_kx_message
==26738==    by 0x35068273DF: _gnutls_handshake_client
==26738==    by 0x3506827F77: gnutls_handshake (gnutls_handshake.c:2193)

Here's what I've been able to figure out. I'm running gnutls 2.0.4, but
I checked 2.4.0, and the affected bits have not changed, the following
should still be applicable.

Hello Sam and thank you for there report. However is this issue present
in 2.4.x or 2.2.x? I've seen that there _gnutls_dh_set_peer_public() is
only called by:
_gnutls_proc_dh_common_client_kx (server side only)
_gnutls_proc_dh_common_server_kx (client side only)

Thus this leak could not have occurred.

Thanks for looking into this. I see what you mean. Initially I did also look at 2.4.0, but I only looked at _gnutls_dh_set_peer_public() and _gnutls_mpi_dprint_lz() and didn't see much changes; but I haven't checked the execution paths in 2.4.0 that reach this function. After compiling against 2.4.0, valgrind no longer shows this leak.

But given that there still does not seem to be an explicit check in _gnutls_mpi_dprint_lz() for a previously-allocated buffer, I'm now wondering what happens if a rehandshake occurs in a middle of a session. I'll try to write some code to test this, against 2.4.0, and see what happens.

Attachment: pgpYkcRyzyEZi.pgp
Description: PGP signature

reply via email to

[Prev in Thread] Current Thread [Next in Thread]