2.5.7 gnutls_x509_privkey_generate() returns GNUTLS_E_INVALID_REQUEST

[Sam Varshavchik]

Nikos Mavrogiannopoulos writes:

> Fix commited. Thank you!

I ran other parts of my app with valgrind compiled against the 2.5.8 
tarball, and I found three more leaks.

The first one:

==1980== 264 (72 direct, 192 indirect) bytes in 3 blocks are definitely lost in loss record 5 of 11
==1980==    at 0x4A0739E: malloc (vg_replace_malloc.c:207)
==1980==    by 0x31584081D0: do_malloc (global.c:558)
==1980==    by 0x31584083D8: _gcry_malloc (global.c:582)
==1980==    by 0x31584083FF: _gcry_xmalloc (global.c:717)
==1980==    by 0x31584443A9: _gcry_mpi_alloc (mpiutil.c:53)
==1980==    by 0x315844138A: _gcry_mpi_scan (mpicoder.c:357)
==1980==    by 0x3158409D44: _gcry_sexp_nth_mpi (sexp.c:691)
==1980==    by 0x4C7600D: _wrap_gcry_pk_sign (pk-libgcrypt.c:380)
==1980==    by 0x4C5E86E: _gnutls_pkcs1_rsa_encrypt (gnutls_pk.c:147)
==1980==    by 0x4C68835: _gnutls_sign (gnutls_sig.c:234)
==1980==    by 0x4C9F601: pkcs1_rsa_sign (sign.c:160)
==1980==    by 0x4C9F86C: _gnutls_x509_sign (sign.c:226)
==1980==    by 0x4C9FACA: _gnutls_x509_sign_tbs (sign.c:290)
==1980==    by 0x4C9FCD5: _gnutls_x509_pkix_sign (sign.c:348)
==1980==    by 0x4CAADC9: gnutls_x509_crt_sign2 (x509_write.c:666)

I think the problem here is in _wrap_gcry_pk_sign(). Line 380:

    res[0] = gcry_sexp_nth_mpi (list, 1, 0);

The return value from gcry_sexp_nth_mpi() appears to be the leak, because on 
a succesful return, this value never gets deallocated.  Also, I see that in 
line 345-367, res[0] and res[1] gets allocated in this fashion, but never 
get allocated. I see all these cleanup deallocations in the cleanup: block, 
at the end of the function, and I see that a number of error paths lead 
there even after the corresponding object is already deallocated. If 
_gnutls_mpi_release() and gcry_sexp_release() can be safely called on an 
object that they've already deallocated, it'll probably be easier just to 
remove the return 0 statement, and let cleanup: handle whatever's not been 
deallocated already.

The second leak:

==1980== 564 bytes in 18 blocks are definitely lost in loss record 7 of 11
==1980==    at 0x4A0739E: malloc (vg_replace_malloc.c:207)
==1980==    by 0x4C8B7E4: _gnutls_x509_write_value (common.c:1071)
==1980==    by 0x4C925E7: set_extension (extensions.c:305)
==1980==    by 0x4C92A71: _gnutls_x509_crt_set_extension (extensions.c:432)

This one's easy.  _gnutls_x509_write_value():

  val.data = gnutls_malloc (asize);     // <----- The allocated memory
  if (val.data == NULL)
    {
      gnutls_assert ();
      result = GNUTLS_E_MEMORY_ERROR;
      goto cleanup;
    }
    
  if (str)
  {
     // Not important

  }
  else
    {
      val.data = data->data;     // <----------- Leaks the malloced pointer
      val.size = data->size;
    }


The third leak:

==1980== 2,370 (504 direct, 1,866 indirect) bytes in 9 blocks are definitely lost in loss record 10 of 11
==1980==    at 0x4A05174: calloc (vg_replace_malloc.c:397)
==1980==    by 0x3158C0A211: (within /usr/lib64/libtasn1.so.3.0.14)
==1980==    by 0x3158C0A3F2: (within /usr/lib64/libtasn1.so.3.0.14)
==1980==    by 0x3158C0A5C2: (within /usr/lib64/libtasn1.so.3.0.14)
==1980==    by 0x3158C0A7E8: asn1_create_element (in /usr/lib64/libtasn1.so.3.0.14)
==1980==    by 0x4C88228: _gnutls_x509_encode_and_write_attribute (dn.c:665)
==1980==    by 0x4C88D42: _gnutls_x509_set_dn_oid (dn.c:915)
==1980==    by 0x4CAA02B: gnutls_x509_crt_set_dn_by_oid (x509_write.c:74)

In _gnutls_x509_encode_and_write_attribute(), there appears to be multiple 
execution paths -- including the successful execution fails, that does not 
call "asn1_delete_structure (&c2)" in order to release what was allocated on 
line 665 by calling asn1_create_element(). Looks like 
asn1_delete_structure(&c2) needs to be shoved right before the comment on 
line 716, after asn1_write_value() succeeds.


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