gmane.comp.encryption.gpg.gnutls.devel

Memory leak in _gnutls_mpi_dprint_lz (possibly _gnutls_mpi_dprint)

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.

_gnutls_mpi_dprint_lz() allocates a buffer:

  if (bytes != 0)
    buf = gnutls_malloc (bytes);

. . . and puts it into its gnutls_datum_t parameter:

  if (!ret)
    {
      dest->data = buf;
      dest->size = bytes;
      return 0;

(Continue reading)

headers

Sam Varshavchik | 28 Jun 02:59

Memory leak in _gnutls_mpi_dprint_lz (possibly _gnutls_mpi_dprint)

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.

_gnutls_mpi_dprint_lz() allocates a buffer:

  if (bytes != 0)
    buf = gnutls_malloc (bytes);

. . . and puts it into its gnutls_datum_t parameter:

  if (!ret)
    {
      dest->data = buf;
      dest->size = bytes;
      return 0;

(Continue reading)

headers

Nikos Mavrogiannopoulos | 29 Jun 11:08

Re: Memory leak in _gnutls_mpi_dprint_lz (possibly _gnutls_mpi_dprint)

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)

(Continue reading)

headers

Sam Varshavchik | 29 Jun 15:17

Re: Memory leak in _gnutls_mpi_dprint_lz (possibly _gnutls_mpi_dprint)

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)

(Continue reading)

headers

Nikos Mavrogiannopoulos | 29 Jun 21:21

Re: Memory leak in _gnutls_mpi_dprint_lz (possibly _gnutls_mpi_dprint)

Sam Varshavchik wrote:

> 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.

You're right, there might be an issue there. I've added some check to
protect against this case.

regards,
Nikos