+++ This bug was initially created as a clone of Bug #911110 +++ Package version and Valgrind trace was updated to match situation in RHEL 6.4. Description of problem: Function lookup_etypes_for_keytab() in krb5-libs leaks memory while working with keytab. Version-Release number of selected component (if applicable): krb5-libs-1.10.3-10.el6.x86_64 How reproducible: 100 % Steps to Reproduce: 1. Create program with krb5_get_init_creds_keytab() 2. Call the program on keytab file with big amount of amount of keys 3. Use valgrind to check your program Actual results: Output from Valgrind. ==10215== at 0x4C279EE: malloc (vg_replace_malloc.c:270) ==10215== by 0x742FEA3: krb5_ktfileint_internal_read_entry (kt_file.c:1253) ==10215== by 0x7431E34: krb5_ktfile_get_next (kt_file.c:1414) ==10215== by 0x7443CF0: krb5_init_creds_set_keytab (gic_keytab.c:101) ==10215== by 0x744409D: get_init_creds_keytab (gic_keytab.c:242) ==10215== by 0x74441B2: krb5_get_init_creds_keytab (gic_keytab.c:284) ==10215== by 0xAF67D6A: get_krb5_tgt (krb5_helper.c:176) ==10215== by 0xAF6D148: ldap_connect (ldap_helper.c:2284) ==10215== by 0xAF759F8: new_ldap_instance (ldap_helper.c:3099) ==10215== by 0xAF79A1D: manager_create_db_instance (zone_manager.c:152) ==10215== by 0xAF696AC: dynamic_driver_init (ldap_driver.c:1364) ==10215== by 0x508FDE5: dns_dynamic_db_load (dynamic_db.c:232) Expected results: No leaks :-) Additional info: AFAIK the memory leak originates in lookup_etypes_for_keytab() function. File gic_keytab.c:101 contains krb5_kt_next_entry() call in a loop, but there is no krb5_kt_free_entry() call in this loop. See code example in manual page http://www.unix.com/man-page/all/3/krb5_kt_free_entry/
This request was not resolved in time for the current release. Red Hat invites you to ask your support representative to propose this request, if still desired, for consideration in the next release of Red Hat Enterprise Linux.
(In reply to comment #0)> AFAIK the memory leak originates in lookup_etypes_for_keytab() function. > File gic_keytab.c:101 contains krb5_kt_next_entry() call in a loop, but > there is no krb5_kt_free_entry() call in this loop. Looks like you're right: there's supposed to be some krb5_free_keytab_entry_contents() action in there.
(In reply to Petr Spacek from comment #0) > Steps to Reproduce: > 1. Create program with krb5_get_init_creds_keytab() Could you please attach such a program? Thank you.
I guess that any program which works with Kerberos keytab should have this problem. In my case I hit the bug with BIND/named: /etc/named.conf contained: tkey-gssapi-credential "DNS/ipa1.example.com"; tkey-domain "EXAMPLE.COM"; You can use FreeIPA server, it will configure named with Kerberos authentication for you. Also, you can try kinit -kt , but I didn't try it.
With a simple kinit -k and using a short keytab file I see the following log from valgrind. It looks very similar to the reported one. Nalin, can you confirm that this is the same error or something else? # valgrind --leak-check=yes kinit -k ==2330== Memcheck, a memory error detector ==2330== Copyright (C) 2002-2012, and GNU GPL'd, by Julian Seward et al. ==2330== Using Valgrind-3.8.1 and LibVEX; rerun with -h for copyright info ==2330== Command: kinit -k ==2330== ==2330== ==2330== HEAP SUMMARY: ==2330== in use at exit: 728 bytes in 36 blocks ==2330== total heap usage: 54,259 allocs, 54,223 frees, 4,919,337 bytes allocated ==2330== ==2330== 104 bytes in 6 blocks are definitely lost in loss record 2 of 5 ==2330== at 0x4C279EE: malloc (vg_replace_malloc.c:270) ==2330== by 0x5719273: krb5_ktfileint_internal_read_entry (kt_file.c:1375) ==2330== by 0x571AE34: krb5_ktfile_get_next (kt_file.c:1414) ==2330== by 0x572CCF0: krb5_init_creds_set_keytab (gic_keytab.c:101) ==2330== by 0x572D09D: get_init_creds_keytab (gic_keytab.c:242) ==2330== by 0x572D1B2: krb5_get_init_creds_keytab (gic_keytab.c:284) ==2330== by 0x10AAFE: k5_kinit (kinit.c:729) ==2330== by 0x10B775: main (kinit.c:844) ==2330== ==2330== 624 (240 direct, 384 indirect) bytes in 6 blocks are definitely lost in loss record 5 of 5 ==2330== at 0x4C279EE: malloc (vg_replace_malloc.c:270) ==2330== by 0x5718EA3: krb5_ktfileint_internal_read_entry (kt_file.c:1253) ==2330== by 0x571AE34: krb5_ktfile_get_next (kt_file.c:1414) ==2330== by 0x572CCF0: krb5_init_creds_set_keytab (gic_keytab.c:101) ==2330== by 0x572D09D: get_init_creds_keytab (gic_keytab.c:242) ==2330== by 0x572D1B2: krb5_get_init_creds_keytab (gic_keytab.c:284) ==2330== by 0x10AAFE: k5_kinit (kinit.c:729) ==2330== by 0x10B775: main (kinit.c:844) ==2330== ==2330== LEAK SUMMARY: ==2330== definitely lost: 344 bytes in 12 blocks ==2330== indirectly lost: 384 bytes in 24 blocks ==2330== possibly lost: 0 bytes in 0 blocks ==2330== still reachable: 0 bytes in 0 blocks ==2330== suppressed: 0 bytes in 0 blocks ==2330== ==2330== For counts of detected and suppressed errors, rerun with: -v ==2330== ERROR SUMMARY: 2 errors from 2 contexts (suppressed: 8 from 6)
This looks like the same traceback to me.