Memory leaks in krb5?

Derrick Schommer schommer at gmail.com
Tue Sep 21 00:16:50 EDT 2004


Tom Yu wrote:
>>>>>>"schommer" == Derrick Schommer <schommer at gmail.com> writes:
> 
> 
> schommer> Its only 28 blocks, but if I repeat the authentication over
> schommer> and over it grows quickly.  It seems that when I get a
> schommer> forwarded tgt (krb5_fwd_tgt() ) and call krb5_rd_cred() it
> schommer> allocates some memory in the asn.1 decoder and I'm not sure
> schommer> why its not cleaned up (or where it should be cleaned up).
> 
> Thanks for noticing this.  By my examination of the code, it appears
> that you are correct.  Ironically, this leak was introduced as part
> of a patch to correct a double-free vulnerability.
> 
> decrypt_credencdata() calls decode_krb5_enc_cred_part(), which
> allocates a krb5_cred_enc_part.  The contents of this
> krb5_cred_enc_part are copied into a krb5_cred_enc_part passed from
> krb5_rd_cred_basic().  krb5_rd_cred_basic() does free the contents of
> its own krb5_cred_enc_part, but the one allocated by
> decrypt_credencdata() is never freed.

Excellent!!  I've got a few others I'm looking at now, but this one was 
killing me.  After a few hours of authentication I start really draining 
memory something fierce (lots of authentications).


Does this one make any sense, I have been getting this one a lot too:

==20711== 16 bytes in 1 blocks are definitely lost in loss record 2 of 10
==20711==    at 0x1B902A90: malloc (vg_replace_malloc.c:131)
==20711==    by 0xC8CC92: krb5int_arcfour_string_to_key (in 
/usr/lib/libk5crypto.so.3.0)
==20711==    by 0xC97A72: krb5_c_string_to_key_with_params (in 
/usr/lib/libk5crypto.so.3.0)
==20711==    by 0x1422B6: (within /usr/lib/libkrb5.so.3.2)
==20711==    by 0x14843C: (within /usr/lib/libkrb5.so.3.2)
==20711==    by 0x149961: krb5_do_preauth (in /usr/lib/libkrb5.so.3.2)
==20711==    by 0x141427: krb5_get_init_creds (in /usr/lib/libkrb5.so.3.2)
==20711==    by 0x142837: krb5_get_init_creds_password (in 
/usr/lib/libkrb5.so.3.2)

I am not sure this is my fault, because all I did was "simply call" 
get_init_creds_password() and there is some string_to_key allocation 
that occurs.  I do a free_cred() on the memory that is returned form the 
creds_password() so I would assume that would clean it all up for me, no?

Thanks,

Derrick


More information about the Kerberos mailing list