Bug 987703 - memleaks in set_krb5_creds
Summary: memleaks in set_krb5_creds
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: 389-ds-base
Version: 6.4
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: rc
: ---
Assignee: Rich Megginson
QA Contact: Sankar Ramalingam
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2013-07-23 23:05 UTC by Nathan Kinder
Modified: 2013-11-21 21:11 UTC (History)
3 users (show)

Fixed In Version: 389-ds-base-1.2.11.15-22.el6
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2013-11-21 21:11:12 UTC
Target Upstream Version:


Attachments (Terms of Use)


Links
System ID Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2013:1653 normal SHIPPED_LIVE 389-ds-base bug fix update 2013-11-20 21:53:19 UTC

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


Note You need to log in before you can comment on or make changes to this bug.