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.i386The 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. |
