Memory leaks in Kerberos 5 1.6.4-beta1 and 1.7

[Dan Searle]

Hi,

I downloaded the krb5-1.7-current snapshot, extracted, cd 
krb5-1.7-current/src, ./configure, cd tests/resolve, make, then ran both 
addrinfo-test and fake-addrinfo-test through valgrind with 
--leack-check=full and --leak-resolution=high.

addrinfo-test:
No leaks.

fake-addrinfo-test:
==23357== 25 bytes in 1 blocks are definitely lost in loss record 1 of 1
==23357==    at 0x4022AB8: malloc (vg_replace_malloc.c:207)
==23357==    by 0x40B9FCF: strdup (in /lib/tls/i686/cmov/libc-2.7.so)
==23357==    by 0x41039D9: (within /lib/tls/i686/cmov/libc-2.7.so)
==23357==    by 0x4105AD8: getaddrinfo (in /lib/tls/i686/cmov/libc-2.7.so)
==23357==    by 0x4030F38: krb5int_getaddrinfo (fake-addrinfo.c:315)
==23357==    by 0x8048AB5: main (addrinfo-test.c:263)
==23357==
==23357== LEAK SUMMARY:
==23357==    definitely lost: 25 bytes in 1 blocks.
==23357==      possibly lost: 0 bytes in 0 blocks.
==23357==    still reachable: 0 bytes in 0 blocks.
==23357==         suppressed: 0 bytes in 0 blocks.

The version of libc6 is the latest available package in Ubuntu Hardy, 
i.e. 2.7-10ubuntu5. Is this a libc bug or an MIT bug?

Regards, Dan...

Ken Raeburn wrote:
> On Nov 6, 2009, at 13:02, Dan Searle wrote:
>   
>> Hi,
>>
>> I tried the patch (applied to the 1.7 public release as I don't have  
>> access to the 1.7.1 branch),
>>     
>
> If you don't have access to the anonymous subversion server, there's a  
> nightly snapshot made available for ftp (but updated only when there  
> are actually changes); info is at http://web.mit.edu/kerberos/krb5-current.html 
>   .  The "krb5-1.7-current" snapshot is from the 1.7.x branch, last  
> updated 9/29 when several bugfixes were incorporated.
>
>
>   
>> however now I get a different leak:
>>
>> ==16212== 50 bytes in 2 blocks are definitely lost in loss record 66  
>> of 81
>> ==16212==    at 0x4022AB8: malloc (vg_replace_malloc.c:207)
>> ==16212==    by 0x4195FCF: strdup (in /lib/tls/i686/cmov/libc-2.7.so)
>> ==16212==    by 0x41DF9D9: (within /lib/tls/i686/cmov/libc-2.7.so)
>> ==16212==    by 0x41E1AD8: getaddrinfo (in /lib/tls/i686/cmov/ 
>> libc-2.7.so)
>> ==16212==    by 0x4279F38: krb5int_getaddrinfo (fake-addrinfo.c:315)
>> ==16212==    by 0x40BE474: krb5_sname_to_principal (sn2princ.c:112)
>> ==16212==    by 0x4042318: krb5_gss_import_name (import_name.c:99)
>> ==16212==    by 0x403703B: gssint_import_internal_name (g_glue.c:306)
>> ==16212==    by 0x403502F: gss_add_cred (g_acquire_cred.c:383)
>> ==16212==    by 0x403535B: gss_acquire_cred (g_acquire_cred.c:198)
>> ==16212==    by 0x8049C31: main (squid_kerb_auth.c:489)
>>
>> Regards, Dan...
>>     
>
> That's storage allocated by the C library's getaddrinfo routine.  As  
> near as I can tell, the fake-addrinfo.c code doesn't mess with the  
> returned structures before freeing them; we just copy the data out  
> into storage we're managing.  So it might be a libc bug.  You could  
> try a little test:
>
> In tests/resolve in your build tree, "make addrinfo-test fake-addrinfo- 
> test".  That builds two programs by the obvious names; one will test  
> the libc getaddrinfo routine, and the other tests our wrapper around  
> it.  Try running both under valgrind, giving the local host name as an  
> argument.  If valgrind reports a leak in addrinfo-test, it's very  
> likely to be a libc bug; if it only reports a problem in fake-addrinfo- 
> test, then it's MIT's bug.
>
> Ken
>
>
>   
> ------------------------------------------------------------------------
>
>
> No virus found in this incoming message.
> Checked by AVG - www.avg.com 
> Version: 9.0.698 / Virus Database: 270.14.52/2484 - Release Date: 11/06/09 07:38: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.