More memory leaks (1.6.4-beta1 release)
Dan Searle
dan.searle at censornet.com
Thu Nov 12 10:18:57 EST 2009
Hi guys,
I've managed to come up with a patch to the krb5-1.6.4-beta1 release
that fixes the critical still reachable memory leaks, please see the
attached file. I would appreciate comments as my "fixes" may have other
side effects I'm unaware of.
Regards, Dan...
Markus Moeller wrote:
> "Marcus Watts" <mdw at umich.edu> wrote in message
> news:E1N8GYL-0005yn-Kd at bruson.ifs.umich.edu...
>
>>> Date: Wed, 11 Nov 2009 13:57:01 GMT
>>> To: krbdev at mit.edu
>>> From: Dan Searle <dan.searle at censornet.com>
>>> Subject: More memory leaks (1.6.4-beta1 release)
>>>
>>> Hi,
>>>
>>> I've been debugging the squid_kerb_auth helper some more and have found
>>> yet more memory leaks. I missed these last round because I didn't take
>>> into account (ignored) the still reachable blocks (malloced blocks which
>>> still have valid pointers).
>>>
>>> I've ignores the instances (loss records) with just 1 block or what seem
>>> to be a "fixed" number of still reachable blocks, i.e. I've only
>>> included here the loss records which seem to scale with the number of
>>> iterations the authentication helper goes through, and so are a threat
>>> to a running process...
>>>
>>> ==5314== 372 bytes in 31 blocks are still reachable in loss record 76 of
>>> 82
>>> ==5314== at 0x4022AB8: malloc (vg_replace_malloc.c:207)
>>> ==5314== by 0x4032BE5: gssint_g_set_entry_add (util_set.c:61)
>>> ==5314== by 0x4033B1B: g_save (util_validate.c:114)
>>> ==5314== by 0x404097A: krb5_gss_acquire_cred (acquire_cred.c:645)
>>> ==5314== by 0x403D23F: krb5_gss_accept_sec_context
>>> (accept_sec_context.c:302)
>>> ==5314== by 0x404B192: k5glue_accept_sec_context (krb5_gss_glue.c:434)
>>> ==5314== by 0x4034178: gss_accept_sec_context
>>> (g_accept_sec_context.c:196)
>>> ==5314== by 0x40510A7: spnego_gss_accept_sec_context
>>> (spnego_mech.c:1113)
>>> ==5314== by 0x4034178: gss_accept_sec_context
>>> (g_accept_sec_context.c:196)
>>> ==5314== by 0x8049C91: main (squid_kerb_auth.c:515)
>>>
>>> ==5314== 372 bytes in 31 blocks are still reachable in loss record 77 of
>>> 82
>>> ==5314== at 0x4022AB8: malloc (vg_replace_malloc.c:207)
>>> ==5314== by 0x40A006A: krb5_ktfile_resolve (kt_file.c:207)
>>> ==5314== by 0x409D900: krb5_kt_resolve (ktbase.c:129)
>>> ==5314== by 0x409DB38: krb5_kt_default (ktdefault.c:41)
>>> ==5314== by 0x4041EC1: krb5_gss_acquire_cred (acquire_cred.c:171)
>>> ==5314== by 0x403D23F: krb5_gss_accept_sec_context
>>> (accept_sec_context.c:302)
>>> ==5314== by 0x404B192: k5glue_accept_sec_context (krb5_gss_glue.c:434)
>>> ==5314== by 0x4034178: gss_accept_sec_context
>>> (g_accept_sec_context.c:196)
>>> ==5314== by 0x40510A7: spnego_gss_accept_sec_context
>>> (spnego_mech.c:1113)
>>> ==5314== by 0x4034178: gss_accept_sec_context
>>> (g_accept_sec_context.c:196)
>>> ==5314== by 0x8049C91: main (squid_kerb_auth.c:515)
>>>
>>> ==5314== 527 bytes in 31 blocks are still reachable in loss record 78 of
>>> 82
>>> ==5314== at 0x4021BDE: calloc (vg_replace_malloc.c:397)
>>> ==5314== by 0x40A013A: krb5_ktfile_resolve (kt_file.c:223)
>>> ==5314== by 0x409D900: krb5_kt_resolve (ktbase.c:129)
>>> ==5314== by 0x409DB38: krb5_kt_default (ktdefault.c:41)
>>> ==5314== by 0x4041EC1: krb5_gss_acquire_cred (acquire_cred.c:171)
>>> ==5314== by 0x403D23F: krb5_gss_accept_sec_context
>>> (accept_sec_context.c:302)
>>> ==5314== by 0x404B192: k5glue_accept_sec_context (krb5_gss_glue.c:434)
>>> ==5314== by 0x4034178: gss_accept_sec_context
>>> (g_accept_sec_context.c:196)
>>> ==5314== by 0x40510A7: spnego_gss_accept_sec_context
>>> (spnego_mech.c:1113)
>>> ==5314== by 0x4034178: gss_accept_sec_context
>>> (g_accept_sec_context.c:196)
>>> ==5314== by 0x8049C91: main (squid_kerb_auth.c:515)
>>>
>>> ==5314== 2,852 bytes in 31 blocks are still reachable in loss record 81
>>> of 82
>>> ==5314== at 0x4022AB8: malloc (vg_replace_malloc.c:207)
>>> ==5314== by 0x403F3C4: krb5_gss_acquire_cred (acquire_cred.c:497)
>>> ==5314== by 0x403D23F: krb5_gss_accept_sec_context
>>> (accept_sec_context.c:302)
>>> ==5314== by 0x404B192: k5glue_accept_sec_context (krb5_gss_glue.c:434)
>>> ==5314== by 0x4034178: gss_accept_sec_context
>>> (g_accept_sec_context.c:196)
>>> ==5314== by 0x40510A7: spnego_gss_accept_sec_context
>>> (spnego_mech.c:1113)
>>> ==5314== by 0x4034178: gss_accept_sec_context
>>> (g_accept_sec_context.c:196)
>>> ==5314== by 0x8049C91: main (squid_kerb_auth.c:515)
>>>
>>> ==5314== 256,308 bytes in 31 blocks are still reachable in loss record
>>> 82 of 82
>>> ==5314== at 0x4022AB8: malloc (vg_replace_malloc.c:207)
>>> ==5314== by 0x40A008A: krb5_ktfile_resolve (kt_file.c:211)
>>> ==5314== by 0x409D900: krb5_kt_resolve (ktbase.c:129)
>>> ==5314== by 0x409DB38: krb5_kt_default (ktdefault.c:41)
>>> ==5314== by 0x4041EC1: krb5_gss_acquire_cred (acquire_cred.c:171)
>>> ==5314== by 0x403D23F: krb5_gss_accept_sec_context
>>> (accept_sec_context.c:302)
>>> ==5314== by 0x404B192: k5glue_accept_sec_context (krb5_gss_glue.c:434)
>>> ==5314== by 0x4034178: gss_accept_sec_context
>>> (g_accept_sec_context.c:196)
>>> ==5314== by 0x40510A7: spnego_gss_accept_sec_context
>>> (spnego_mech.c:1113)
>>> ==5314== by 0x4034178: gss_accept_sec_context
>>> (g_accept_sec_context.c:196)
>>> ==5314== by 0x8049C91: main (squid_kerb_auth.c:515)
>>>
>>> I've also debugged the squid_kerb_auth helper code and made sure it
>>> matches calls to gss_accept_sec_context() with calls to
>>> gss_delete_sec_context() which it does. So these still reachable leaks
>>> do appear to be bugs in the MIT Kerberos libs.
>>>
>>> Can anyone shed any light on these? as they are making MIT Kerberos
>>> unusable. Regards, Dan...
>>>
>>> --
>>> Dan Searle
>>>
>>> CensorNet Ltd - professional & affordable Web & E-mail filtering
>>> email: dan.searle at censornet.com web: www.censornet.com
>>> tel: 0845 230 9590 / fax: 0845 230 9591 / support: 0845 230 9592
>>> snail: Vallon House, Vantage Court Office Park, Winterbourne,
>>> Bristol, BS16 1GW, UK.
>>>
>>> CensorNet Ltd is a registered company in England & Wales No. 05518629
>>> VAT registration number 901-2048-78
>>> Any views expressed in this email communication are those of the
>>> individual sender, except where the sender specifically states them to
>>> be the views of a member of Censornet Ltd. Censornet Ltd. does not
>>> represent, warrant or guarantee that the integrity of this
>>> communication has been maintained nor that the communication is free
>>> of errors or interference.
>>>
>>>
>>> -------------------------------------------------------------------------------
>>> -----
>>> Scanned for viruses, spam and offensive content by CensorNet MailSafe
>>>
>>> Try CensorNet free for 14 days. Provide Internet access on your terms.
>>> Visit www.censornet.com for more information.
>>>
>>> _______________________________________________
>>> krbdev mailing list krbdev at mit.edu
>>> https://mailman.mit.edu/mailman/listinfo/krbdev
>>>
>> Presumably your iteration count in this sample was 31.
>> 3 of your 5 loss records are associated with calls to
>> krb5_ktfile_resolve. Calls to krb5_ktfile_resolve/krb5_kt_default
>> should be balanced with calls to krb5_ktfile_close.
>> The relevant logic is in krb5/src/lib/gssapi/krb5/acquire_cred.c
>> so that's presumably where the missing krb5_ktfile_close call ought
>> to be.
>>
>> Both your remaining loss records are directly from gssapi.
>> specifically krb5_gss_acquire_cred. It looks like calls to that
>> should be paired up with calls to krb5_gss_release_cred.
>> That could happen at the end of krb5_gss_accept_sec_context
>> if verifier_cred_handle is passed as 0, otherwise, it looks like
>> the application (squid?) should be responsible.
>>
>
> This is a standalone application. All interaction with squid is via stdin
> (base64 encoded token) and stdout.
>
>
>> Presumably the
>> squid code should actually be calling gss_release_cred.
>> It's possible there's a bug here in the MIT code, but it would be
>> useful to first establish the credential isn't in fact being
>> passed out to squid.
>>
>>
>
> I tested in the past several MIT/Heimdal versions on different Linux
> distributions. Some distribution have fixed MIT memory leaks others haven't.
> I think my squid_kerb_auth code is correct in freeing allocated memory (at
> least i have seen one or two Linux distributions e.g. centos which don't
> show leaks)
>
>
>> -Marcus Watts
>> _______________________________________________
>> krbdev mailing list krbdev at mit.edu
>> https://mailman.mit.edu/mailman/listinfo/krbdev
>>
>>
> Regards
> Markus
>
>
> _______________________________________________
> krbdev mailing list krbdev at mit.edu
> https://mailman.mit.edu/mailman/listinfo/krbdev
>
> ------------------------------------------------------------------------------------
> Scanned for viruses, spam and offensive content by CensorNet MailSafe
>
> Try CensorNet free for 14 days. Provide Internet access on your terms.
> Visit www.censornet.com for more information.
>
> ------------------------------------------------------------------------
>
>
> No virus found in this incoming message.
> Checked by AVG - www.avg.com
> Version: 9.0.704 / Virus Database: 270.14.60/2496 - Release Date: 11/11/09 07:40:00
>
>
--
Dan Searle
CensorNet Ltd - professional & affordable Web & E-mail filtering
email: dan.searle at censornet.com web: www.censornet.com
tel: 0845 230 9590 / fax: 0845 230 9591 / support: 0845 230 9592
snail: Vallon House, Vantage Court Office Park, Winterbourne,
Bristol, BS16 1GW, UK.
CensorNet Ltd is a registered company in England & Wales No. 05518629
VAT registration number 901-2048-78
Any views expressed in this email communication are those of the
individual sender, except where the sender specifically states them to
be the views of a member of Censornet Ltd. Censornet Ltd. does not
represent, warrant or guarantee that the integrity of this
communication has been maintained nor that the communication is free
of errors or interference.
------------------------------------------------------------------------------------
Scanned for viruses, spam and offensive content by CensorNet MailSafe
Try CensorNet free for 14 days. Provide Internet access on your terms.
Visit www.censornet.com for more information.
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: krb5-1.6.4-beta1.patch
Url: http://mailman.mit.edu/pipermail/krbdev/attachments/20091112/c5f9199c/attachment.bat
More information about the krbdev
mailing list