gnutls-devel
[Top][All Lists]
Advanced

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

[gnutls-dev] Minor libtasn1 bug


From: Stephen Wrobleski
Subject: [gnutls-dev] Minor libtasn1 bug
Date: Tue, 19 Sep 2006 02:03:37 -0400
User-agent: Mutt/1.5.13 (2006-08-11)

I've come across a relatively minor bug in libtasn1-0.3.5. In the following
snippet, I first find out how long of a buffer is necessary, allocate
exactly that size buffer, and then do the real coding.

{
  char *der, *err;
  int  der_len, ret;

  /* find out the size of the coding */
  der_len = 0;
  ret = asn1_der_coding(hashkey, "", NULL, &der_len, err);
  assert(ret == ASN1_MEM_ERROR);

  der = malloc(der_len);

  ret = asn1_der_coding(hashkey, "", der, &der_len, err);
  assert(ret == ASN1_SUCCESS);
}

The second asn1_der_coding() call fails, complaining about too short of a
buffer length. I've only seen this happen when I'm attempting to encode a
NULL type (it's also implicitly tagged, by the way). I've looked in the
source for 0.3.5, as well as the cvs version as of 18SEP2006, and believe
the problem to be the lines

if (max_len >= 0)
  der[counter++] = 0;

in the TYPE_NULL coding section of the function itself (in coding.c).
Specifically, every other section increments 'counter' regardless of whether
we write to the buffer or not. This section doesn't.

I'm running against the Debian binary package (0.3.5-2). As this problem is
pretty easy to work around (for now), I've resisted building from source. I
think this should be pretty easy to independently verify and fix. Please let
me know if more information happens to be required.


Thanks,
Steve



reply via email to

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