[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[gnutls-dev] Re: Minor libtasn1 bug
From: |
Simon Josefsson |
Subject: |
[gnutls-dev] Re: Minor libtasn1 bug |
Date: |
Tue, 19 Sep 2006 12:27:13 +0200 |
User-agent: |
Gnus/5.110006 (No Gnus v0.6) Emacs/22.0.50 (gnu/linux) |
Stephen Wrobleski <address@hidden> 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.
Thanks,
Simon