[gnutls-dev] Re: Minor libtasn1 bug

Simon Josefsson jas at extundo.com
Tue Sep 19 12:27:13 CEST 2006

Stephen Wrobleski <steve at localtoast.org> writes:

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

Your analysis looks correct to me, and the code looks wrong.  I've
fixed this in CVS, for 0.3.7.


More information about the Gnutls-devel mailing list