More memory leaks (1.6.4-beta1 release)

[Dan Searle]

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.