[18879] in Kerberos_V5_Development
Re: krb5_free_data
daemon@ATHENA.MIT.EDU (Greg Hudson)
Sun Jun 22 10:08:09 2014
Message-ID: <53A6E33E.2020702@mit.edu>
Date: Sun, 22 Jun 2014 10:07:58 -0400
From: Greg Hudson <ghudson@mit.edu>
MIME-Version: 1.0
To: Markus Moeller <huaraz@moeller.plus.com>, krbdev@mit.edu
In-Reply-To: <lo6gpd$mqr$1@ger.gmane.org>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Errors-To: krbdev-bounces@mit.edu
On 06/22/2014 08:04 AM, Markus Moeller wrote:
> I see. So if k5_pac_locate_buffer returns with an error I may get this
> problem ?
Your code begins with:
>> ad_data = (krb5_data *)xmalloc(sizeof(krb5_data));
After this line, ad_data->data and ad_data->length are uninitialized.
If you were to immediately call krb5_free_data(context, ad_data) without
doing anything else, you would often see a crash because ad_data->data
is heap garbage.
If you use calloc instead of malloc, or call "memset(ad_data, 0,
sizeof(krb5_data))" after allocating, then you avoid this state.
(Strictly speaking, the C standard says that zeroed memory and null
pointers aren't necessarily the same thing, but lots of C code ignores
this and assumes that they are. See http://c-faq.com/null/ for more on
that.)
Your code goes on to call:
>> #define KERB_LOGON_INFO 1
>> ret = krb5_pac_get_buffer(context, pac, KERB_LOGON_INFO, ad_data);
If krb5_pac_get_buffer succeeds, ad_data->data and ad_data->length will
be filled in with the results, and you can safely free ad_data.
If it fails, it currently doesn't touch ad_data at all, leaving it
uninitialized and therefore unsafe to free. Tom refers to this as
"probably a bug," but it's not uncommon for older libkrb5 APIs. To be
safe, do not assume that libkrb5 APIs will initialize their output
parameters when they fail.
_______________________________________________
krbdev mailing list krbdev@mit.edu
https://mailman.mit.edu/mailman/listinfo/krbdev
