Bug 987703

Summary: memleaks in set_krb5_creds
Product: Red Hat Enterprise Linux 6 Reporter: Nathan Kinder <nkinder>
Component: 389-ds-baseAssignee: Rich Megginson <rmeggins>
Status: CLOSED ERRATA QA Contact: Sankar Ramalingam <sramling>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 6.4CC: jgalipea, jrusnack, nhosoi
Target Milestone: rc   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: 389-ds-base-1.2.11.15-22.el6 Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2013-11-21 21:11:12 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Nathan Kinder 2013-07-23 23:05:52 UTC
This bug is created as a clone of upstream ticket:
https://fedorahosted.org/389/ticket/47421

Steps:
1) Setup 2 way MMR using SASL/GSSAPI/kerberos for the replication transport/bind.
2) run 1 of the servers using valgrind
3) do a bunch of add operations against both servers

{{{
==6228== 104 bytes in 6 blocks are definitely lost in loss record 1,014 of 1,560
==6228==    at 0x4A069EE: malloc (vg_replace_malloc.c:270)
==6228==    by 0x32CC24B273: krb5_ktfileint_internal_read_entry (kt_file.c:1375)
==6228==    by 0x32CC24CE34: krb5_ktfile_get_next (kt_file.c:1414)
==6228==    by 0x32CC25ECF0: krb5_init_creds_set_keytab (gic_keytab.c:101)
==6228==    by 0x32CC25F09D: get_init_creds_keytab (gic_keytab.c:242)
==6228==    by 0x32CC25F1B2: krb5_get_init_creds_keytab (gic_keytab.c:284)
==6228==    by 0x4C823B2: set_krb5_creds (ldaputil.c:1952)
==6228==    by 0x4C80C8C: ldap_sasl_set_interact_vals (ldaputil.c:1354)
==6228==    by 0x4C81004: slapd_ldap_sasl_interactive_bind (ldaputil.c:1470)
==6228==    by 0x4C8078C: slapi_ldap_bind (ldaputil.c:1159)
==6228==    by 0x9DBA475: bind_and_check_pwp (repl5_connection.c:1784)
==6228==    by 0x9DB9025: conn_connect (repl5_connection.c:1150)
==6228==    by 0x9DC3FD7: acquire_replica (repl5_protocol_util.c:169)
==6228==    by 0x9DBBA51: repl5_inc_run (repl5_inc_protocol.c:791)
==6228==    by 0x9DC3546: prot_thread_main (repl5_protocol.c:319)
==6228==    by 0x3DABA29B52: _pt_root (ptthread.c:156)
==6228==    by 0x3D3CE07850: start_thread (pthread_create.c:301)
==6228==    by 0x3D3C2E890C: clone (clone.S:115)
}}}
not sure what this is - may be due to below
{{{
==6228== 126 bytes in 3 blocks are definitely lost in loss record 1,052 of 1,560
==6228==    at 0x4A069EE: malloc (vg_replace_malloc.c:270)
==6228==    by 0x32CC2791EA: k5_unparse_name (unparse.c:201)
==6228==    by 0x4C81D77: set_krb5_creds (ldaputil.c:1821)
==6228==    by 0x4C80C8C: ldap_sasl_set_interact_vals (ldaputil.c:1354)
==6228==    by 0x4C81004: slapd_ldap_sasl_interactive_bind (ldaputil.c:1470)
==6228==    by 0x4C8078C: slapi_ldap_bind (ldaputil.c:1159)
==6228==    by 0x9DBA475: bind_and_check_pwp (repl5_connection.c:1784)
==6228==    by 0x9DB9025: conn_connect (repl5_connection.c:1150)
==6228==    by 0x9DC3FD7: acquire_replica (repl5_protocol_util.c:169)
==6228==    by 0x9DBBA51: repl5_inc_run (repl5_inc_protocol.c:791)
==6228==    by 0x9DC3546: prot_thread_main (repl5_protocol.c:319)
==6228==    by 0x3DABA29B52: _pt_root (ptthread.c:156)
==6228==    by 0x3D3CE07850: start_thread (pthread_create.c:301)
==6228==    by 0x3D3C2E890C: clone (clone.S:115)
==6228==
}}}
We call krb5_unparse_name() on line 1904 which will overwrite princ_name if it is already set on line 1821 - must free princ_name first.
{{{
==6228== 336 (120 direct, 216 indirect) bytes in 3 blocks are definitely lost in loss record 1,263 of 1,560
==6228==    at 0x4A069EE: malloc (vg_replace_malloc.c:270)
==6228==    by 0x32CC255382: krb5_copy_principal (copy_princ.c:38)
==6228==    by 0x4C81C83: set_krb5_creds (ldaputil.c:1804)
==6228==    by 0x4C80C8C: ldap_sasl_set_interact_vals (ldaputil.c:1354)
==6228==    by 0x4C81004: slapd_ldap_sasl_interactive_bind (ldaputil.c:1470)
==6228==    by 0x4C8078C: slapi_ldap_bind (ldaputil.c:1159)
==6228==    by 0x9DBA475: bind_and_check_pwp (repl5_connection.c:1784)
==6228==    by 0x9DB9025: conn_connect (repl5_connection.c:1150)
==6228==    by 0x9DC3FD7: acquire_replica (repl5_protocol_util.c:169)
==6228==    by 0x9DBBA51: repl5_inc_run (repl5_inc_protocol.c:791)
==6228==    by 0x9DC3546: prot_thread_main (repl5_protocol.c:319)
==6228==    by 0x3DABA29B52: _pt_root (ptthread.c:156)
==6228==    by 0x3D3CE07850: start_thread (pthread_create.c:301)
==6228==    by 0x3D3C2E890C: clone (clone.S:115)
}}}
{{{
==6228== 684 (240 direct, 444 indirect) bytes in 6 blocks are definitely lost in loss record 1,365 of 1,560
==6228==    at 0x4A069EE: malloc (vg_replace_malloc.c:270)
==6228==    by 0x32CC24AEA3: krb5_ktfileint_internal_read_entry (kt_file.c:1253)
==6228==    by 0x32CC24CE34: krb5_ktfile_get_next (kt_file.c:1414)
==6228==    by 0x32CC25ECF0: krb5_init_creds_set_keytab (gic_keytab.c:101)
==6228==    by 0x32CC25F09D: get_init_creds_keytab (gic_keytab.c:242)
==6228==    by 0x32CC25F1B2: krb5_get_init_creds_keytab (gic_keytab.c:284)
==6228==    by 0x4C823B2: set_krb5_creds (ldaputil.c:1952)
==6228==    by 0x4C80C8C: ldap_sasl_set_interact_vals (ldaputil.c:1354)
==6228==    by 0x4C81004: slapd_ldap_sasl_interactive_bind (ldaputil.c:1470)
==6228==    by 0x4C8078C: slapi_ldap_bind (ldaputil.c:1159)
==6228==    by 0x9DBA475: bind_and_check_pwp (repl5_connection.c:1784)
==6228==    by 0x9DB9025: conn_connect (repl5_connection.c:1150)
==6228==    by 0x9DC3FD7: acquire_replica (repl5_protocol_util.c:169)
==6228==    by 0x9DBBA51: repl5_inc_run (repl5_inc_protocol.c:791)
==6228==    by 0x9DC3546: prot_thread_main (repl5_protocol.c:319)
==6228==    by 0x3DABA29B52: _pt_root (ptthread.c:156)
==6228==    by 0x3D3CE07850: start_thread (pthread_create.c:301)
==6228==    by 0x3D3C2E890C: clone (clone.S:115)
}}}

Comment 2 Ján Rusnačko 2013-09-30 10:31:53 UTC
On 389-ds-base-1.2.11.15-26.el6.x86_64:

set up 2MMR with SASL/GSSAPI auth, added and deleted 1000 users (500 per server).


==3777== 104 bytes in 6 blocks are definitely lost in loss record 1,123 of 1,781
==3777==    at 0x4A069EE: malloc (vg_replace_malloc.c:270)
==3777==    by 0x38F444B273: krb5_ktfileint_internal_read_entry (kt_file.c:1375)
==3777==    by 0x38F444CE34: krb5_ktfile_get_next (kt_file.c:1414)
==3777==    by 0x38F445ECF0: krb5_init_creds_set_keytab (gic_keytab.c:101)
==3777==    by 0x38F445F09D: get_init_creds_keytab (gic_keytab.c:242)
==3777==    by 0x38F445F1B2: krb5_get_init_creds_keytab (gic_keytab.c:284)
==3777==    by 0x4C7562A: set_krb5_creds (ldaputil.c:1953)
==3777==    by 0x4C75D7C: slapd_ldap_sasl_interactive_bind (ldaputil.c:1354)
==3777==    by 0x4C7614E: slapi_ldap_bind (ldaputil.c:1159)
==3777==    by 0x9B3061B: conn_connect (repl5_connection.c:1784)
==3777==    by 0x9B39CCF: acquire_replica (repl5_protocol_util.c:169)
==3777==    by 0x9B33B92: repl5_inc_run (repl5_inc_protocol.c:791)
==3777==    by 0x9B39054: prot_thread_main (repl5_protocol.c:319)
==3777==    by 0x38F5429A72: _pt_root (ptthread.c:156)
==3777==    by 0x38E7407850: start_thread (pthread_create.c:301)
==3777==    by 0x38E70E890C: clone (clone.S:115)

==3777== 642 (240 direct, 402 indirect) bytes in 6 blocks are definitely lost in loss record 1,452 of 1,781
==3777==    at 0x4A069EE: malloc (vg_replace_malloc.c:270)
==3777==    by 0x38F444AEA3: krb5_ktfileint_internal_read_entry (kt_file.c:1253)
==3777==    by 0x38F444CE34: krb5_ktfile_get_next (kt_file.c:1414)
==3777==    by 0x38F445ECF0: krb5_init_creds_set_keytab (gic_keytab.c:101)
==3777==    by 0x38F445F09D: get_init_creds_keytab (gic_keytab.c:242)
==3777==    by 0x38F445F1B2: krb5_get_init_creds_keytab (gic_keytab.c:284)
==3777==    by 0x4C7562A: set_krb5_creds (ldaputil.c:1953)
==3777==    by 0x4C75D7C: slapd_ldap_sasl_interactive_bind (ldaputil.c:1354)
==3777==    by 0x4C7614E: slapi_ldap_bind (ldaputil.c:1159)
==3777==    by 0x9B3061B: conn_connect (repl5_connection.c:1784)
==3777==    by 0x9B39CCF: acquire_replica (repl5_protocol_util.c:169)
==3777==    by 0x9B33B92: repl5_inc_run (repl5_inc_protocol.c:791)
==3777==    by 0x9B39054: prot_thread_main (repl5_protocol.c:319)
==3777==    by 0x38F5429A72: _pt_root (ptthread.c:156)
==3777==    by 0x38E7407850: start_thread (pthread_create.c:301)
==3777==    by 0x38E70E890C: clone (clone.S:115)

Reopening the bug.

Comment 3 Noriko Hosoi 2013-10-01 22:12:34 UTC
Hi Ján,

Could you please double check the version of krb5 in your environment?  We learned from Nalin that a very similar memory leak bug was fixed in krb5 recently.  krb5-1.10.3-10.el6_4.4 and later have the fix.

We've rebuilt 389-ds-base-1.2.11.15-27.el6 just now (the respin has nothing to do on this memory leak bug, though.  but that's the latest and greatest for now.).  Could you please rerun the valgrind test using the combination: krb5-1.10.3-10.el6_4.4 or newer + 89-ds-base-1.2.11.15-27.el6?

Thank you!!

Comment 4 Ján Rusnačko 2013-10-02 11:59:17 UTC
I have verified with 389-ds-base-1.2.11.15-27.el6.x86_64 and krb5-workstation-1.10.3-10.el6_4.4.x86_64 that there are no memory leaks related to krb5.

Comment 5 errata-xmlrpc 2013-11-21 21:11:12 UTC
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

http://rhn.redhat.com/errata/RHBA-2013-1653.html