Memory leak in _gnutls_mpi_dprint_lz (possibly _gnutls_mpi_dprint)

[Sam Varshavchik]

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
>> (gnutls_state.c:474)
>> ==26738==    by 0x3506843819: _gnutls_proc_dh_common_server_kx
>> (auth_dh_common.c:297)
>> ==26738==    by 0x350683BB4F: proc_dhe_server_kx (auth_dhe.c:199)
>> ==26738==    by 0x350682AF81: _gnutls_recv_server_kx_message
>> (gnutls_kx.c:339)
>> ==26738==    by 0x35068273DF: _gnutls_handshake_client
>> (gnutls_handshake.c:2311)
>> ==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.


-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
URL: </pipermail/attachments/20080629/5c518d94/attachment.pgp>