Bug 987703 - memleaks in set_krb5_creds
memleaks in set_krb5_creds
Status: CLOSED ERRATA
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: 389-ds-base (Show other bugs)
6.4
Unspecified Unspecified
unspecified Severity unspecified
: rc
: ---
Assigned To: Rich Megginson
Sankar Ramalingam
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2013-07-23 19:05 EDT by Nathan Kinder
Modified: 2013-11-21 16:11 EST (History)
3 users (show)

See Also:
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 16:11:12 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Nathan Kinder 2013-07-23 19:05:52 EDT
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 06:31:53 EDT
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 18:12:34 EDT
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 07:59:17 EDT
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 16:11:12 EST
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.