Memory leaks in krb5?
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
==20711== by 0xC97A72: krb5_c_string_to_key_with_params (in
==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
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?
More information about the Kerberos