Heap Corruption with large authorization header values

[Greg Hudson]

On 11/12/2014 06:58 PM, Tim Vega wrote:
> We ran into another bug of a similar nature
> 
> Line 868 of src\lib\gssapi\krb5\accept_sec_context.c:
> if ((ctx = (krb5_gss_ctx_id_rec *) xmalloc(sizeof(krb5_gss_ctx_id_rec)))

I don't think that's a bug.  krb5_gss_ctx_id_rec structures are freed
within the krb5 mech with xfree (at delete_sec_context.c line 91), not
in the mechglue with gssalloc_free.

> Would it also be safe to change this xmalloc call to gssalloc_malloc? We're concerned with running into more of the same as well. Is there some sort of systematic rule we can use to determine if it's safe to convert xmalloc calls to gssalloc_malloc?

A gss_buffer_desc value returned to the caller must use gssalloc_malloc.
 Everything else should continue using malloc/free.  (xmalloc/xfree are
just #defines for malloc and free, which we will probably get rid of at
some point.)