Valgrind reported problem with ldap_sasl_interactive_bind_s
Howard Wilkinson
howard at cohtech.com
Tue Dec 2 05:20:12 EST 2008
I have been doing some development on the nss_ldap library and have been
getting valgrind errors reported. I have managed to reproduce these by
running ldapsearch. This system is a Fedora 9 environment patched up to
the latest updates as of today! Running the following packages.
openldap-2.4.10-2.fc9.i386
cyrus-sasl-2.1.22-15.fc9.i386
krb5-libs-1.6.3-10.fc9.i386
glibc-2.8-8.i686
The output from valgrind is as follows!
==29134== Conditional jump or move depends on uninitialised value(s)
==29134== at 0x5F18CA: k5_arcfour_init (rc4.c:94)
==29134== by 0x5F1AAB: k5_arcfour_docrypt (rc4.c:150)
==29134== by 0x76D332: kg_get_seq_num (util_seqnum.c:74)
==29134== by 0x76D98C: kg_make_seq_num (val_cred.c:56)
==29134== by 0x767BCC: rotate_left (string3.h:52)
==29134== by 0x76B25E: krb5_gss_seal (set_allowable_enctypes.c:104)
==29134== by 0x76A096: gss_krb5_get_tkt_flags (krb5_gss_glue.c:1035)
==29134== by 0x75A739: gss_unseal (g_unseal.c:84)
==29134== by 0x75A796: gss_unwrap (g_unseal.c:119)
==29134== by 0x479F0B8: gssapi_client_mech_step (gssapi.c:1680)
==29134== by 0x14468A: sasl_client_step (client.c:655)
==29134== by 0x3167AB: ldap_int_sasl_bind (cyrus.c:801)
==29134==
==29134== Conditional jump or move depends on uninitialised value(s)
==29134== at 0x5F18CC: k5_arcfour_init (rc4.c:94)
==29134== by 0x5F1AAB: k5_arcfour_docrypt (rc4.c:150)
==29134== by 0x76D332: kg_get_seq_num (util_seqnum.c:74)
==29134== by 0x76D98C: kg_make_seq_num (val_cred.c:56)
==29134== by 0x767BCC: rotate_left (string3.h:52)
==29134== by 0x76B25E: krb5_gss_seal (set_allowable_enctypes.c:104)
==29134== by 0x76A096: gss_krb5_get_tkt_flags (krb5_gss_glue.c:1035)
==29134== by 0x75A739: gss_unseal (g_unseal.c:84)
==29134== by 0x75A796: gss_unwrap (g_unseal.c:119)
==29134== by 0x479F0B8: gssapi_client_mech_step (gssapi.c:1680)
==29134== by 0x14468A: sasl_client_step (client.c:655)
==29134== by 0x3167AB: ldap_int_sasl_bind (cyrus.c:801)
==29134==
==29134== Use of uninitialised value of size 4
==29134== at 0x5F192B: k5_arcfour_init (rc4.c:109)
==29134== by 0x5F1AAB: k5_arcfour_docrypt (rc4.c:150)
==29134== by 0x76D332: kg_get_seq_num (util_seqnum.c:74)
==29134== by 0x76D98C: kg_make_seq_num (val_cred.c:56)
==29134== by 0x767BCC: rotate_left (string3.h:52)
==29134== by 0x76B25E: krb5_gss_seal (set_allowable_enctypes.c:104)
==29134== by 0x76A096: gss_krb5_get_tkt_flags (krb5_gss_glue.c:1035)
==29134== by 0x75A739: gss_unseal (g_unseal.c:84)
==29134== by 0x75A796: gss_unwrap (g_unseal.c:119)
==29134== by 0x479F0B8: gssapi_client_mech_step (gssapi.c:1680)
==29134== by 0x14468A: sasl_client_step (client.c:655)
==29134== by 0x3167AB: ldap_int_sasl_bind (cyrus.c:801)
==29134==
==29134== Use of uninitialised value of size 4
==29134== at 0x5F1936: k5_arcfour_init (rc4.c:110)
==29134== by 0x5F1AAB: k5_arcfour_docrypt (rc4.c:150)
==29134== by 0x76D332: kg_get_seq_num (util_seqnum.c:74)
==29134== by 0x76D98C: kg_make_seq_num (val_cred.c:56)
==29134== by 0x767BCC: rotate_left (string3.h:52)
==29134== by 0x76B25E: krb5_gss_seal (set_allowable_enctypes.c:104)
==29134== by 0x76A096: gss_krb5_get_tkt_flags (krb5_gss_glue.c:1035)
==29134== by 0x75A739: gss_unseal (g_unseal.c:84)
==29134== by 0x75A796: gss_unwrap (g_unseal.c:119)
==29134== by 0x479F0B8: gssapi_client_mech_step (gssapi.c:1680)
==29134== by 0x14468A: sasl_client_step (client.c:655)
==29134== by 0x3167AB: ldap_int_sasl_bind (cyrus.c:801)
==29134==
==29134== Syscall param write(buf) points to uninitialised byte(s)
==29134== at 0xC3DF73: __write_nocancel (in /lib/libc-2.8.so)
==29134== by 0x1C83B1: sb_debug_write (sockbuf.c:852)
==29134== by 0x1C8821: ber_int_sb_write (sockbuf.c:445)
==29134== by 0x1C5F23: ber_flush2 (io.c:256)
==29134== by 0x3242C8: ldap_int_flush_request (request.c:152)
==29134== by 0x3246BE: ldap_send_server_request (request.c:348)
==29134== by 0x3248A1: ldap_send_initial_request (request.c:136)
==29134== by 0x318FB1: ldap_sasl_bind (sasl.c:148)
==29134== by 0x319287: ldap_sasl_bind_s (sasl.c:182)
==29134== by 0x316575: ldap_int_sasl_bind (cyrus.c:737)
==29134== by 0x318A15: ldap_sasl_interactive_bind_s (sasl.c:464)
==29134== by 0x804FF62: tool_bind (common.c:1336)
==29134== Address 0x4048e3d is 53 bytes inside a block of size 4,060
alloc'd
==29134== at 0x4006AEE: malloc (vg_replace_malloc.c:207)
==29134== by 0x1C6F3F: ber_memalloc_x (memory.c:226)
==29134== by 0x1C799B: ber_memrealloc_x (memory.c:304)
==29134== by 0x1C6149: ber_realloc (io.c:155)
==29134== by 0x1C6313: ber_write (io.c:114)
==29134== by 0x1C3516: ber_put_tag (encode.c:100)
==29134== by 0x1C3D7F: ber_put_int_or_enum (encode.c:284)
==29134== by 0x1C4B25: ber_printf (encode.c:774)
==29134== by 0x318F45: ldap_sasl_bind (sasl.c:122)
==29134== by 0x319287: ldap_sasl_bind_s (sasl.c:182)
==29134== by 0x316575: ldap_int_sasl_bind (cyrus.c:737)
==29134== by 0x318A15: ldap_sasl_interactive_bind_s (sasl.c:464)
Does anybody have any idea where the uninitialised memory is coming
from? I have tried to trace backwards from the kerberos libraries but
with no real joy!
Howard.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.andrew.cmu.edu/pipermail/cyrus-sasl/attachments/20081202/2b9020ee/attachment.html
More information about the Cyrus-sasl
mailing list