<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
</head>
<body bgcolor="#ffffff" text="#000000">
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.<br>
<blockquote>openldap-2.4.10-2.fc9.i386<br>
cyrus-sasl-2.1.22-15.fc9.i386<br>
krb5-libs-1.6.3-10.fc9.i386<br>
glibc-2.8-8.i686<br>
</blockquote>
The output from valgrind is as follows!<br>
<br>
<br>
==29134== Conditional jump or move depends on uninitialised value(s)<br>
==29134== at 0x5F18CA: k5_arcfour_init (rc4.c:94)<br>
==29134== by 0x5F1AAB: k5_arcfour_docrypt (rc4.c:150)<br>
==29134== by 0x76D332: kg_get_seq_num (util_seqnum.c:74)<br>
==29134== by 0x76D98C: kg_make_seq_num (val_cred.c:56)<br>
==29134== by 0x767BCC: rotate_left (string3.h:52)<br>
==29134== by 0x76B25E: krb5_gss_seal (set_allowable_enctypes.c:104)<br>
==29134== by 0x76A096: gss_krb5_get_tkt_flags (krb5_gss_glue.c:1035)<br>
==29134== by 0x75A739: gss_unseal (g_unseal.c:84)<br>
==29134== by 0x75A796: gss_unwrap (g_unseal.c:119)<br>
==29134== by 0x479F0B8: gssapi_client_mech_step (gssapi.c:1680)<br>
==29134== by 0x14468A: sasl_client_step (client.c:655)<br>
==29134== by 0x3167AB: ldap_int_sasl_bind (cyrus.c:801)<br>
==29134== <br>
==29134== Conditional jump or move depends on uninitialised value(s)<br>
==29134== at 0x5F18CC: k5_arcfour_init (rc4.c:94)<br>
==29134== by 0x5F1AAB: k5_arcfour_docrypt (rc4.c:150)<br>
==29134== by 0x76D332: kg_get_seq_num (util_seqnum.c:74)<br>
==29134== by 0x76D98C: kg_make_seq_num (val_cred.c:56)<br>
==29134== by 0x767BCC: rotate_left (string3.h:52)<br>
==29134== by 0x76B25E: krb5_gss_seal (set_allowable_enctypes.c:104)<br>
==29134== by 0x76A096: gss_krb5_get_tkt_flags (krb5_gss_glue.c:1035)<br>
==29134== by 0x75A739: gss_unseal (g_unseal.c:84)<br>
==29134== by 0x75A796: gss_unwrap (g_unseal.c:119)<br>
==29134== by 0x479F0B8: gssapi_client_mech_step (gssapi.c:1680)<br>
==29134== by 0x14468A: sasl_client_step (client.c:655)<br>
==29134== by 0x3167AB: ldap_int_sasl_bind (cyrus.c:801)<br>
==29134== <br>
==29134== Use of uninitialised value of size 4<br>
==29134== at 0x5F192B: k5_arcfour_init (rc4.c:109)<br>
==29134== by 0x5F1AAB: k5_arcfour_docrypt (rc4.c:150)<br>
==29134== by 0x76D332: kg_get_seq_num (util_seqnum.c:74)<br>
==29134== by 0x76D98C: kg_make_seq_num (val_cred.c:56)<br>
==29134== by 0x767BCC: rotate_left (string3.h:52)<br>
==29134== by 0x76B25E: krb5_gss_seal (set_allowable_enctypes.c:104)<br>
==29134== by 0x76A096: gss_krb5_get_tkt_flags (krb5_gss_glue.c:1035)<br>
==29134== by 0x75A739: gss_unseal (g_unseal.c:84)<br>
==29134== by 0x75A796: gss_unwrap (g_unseal.c:119)<br>
==29134== by 0x479F0B8: gssapi_client_mech_step (gssapi.c:1680)<br>
==29134== by 0x14468A: sasl_client_step (client.c:655)<br>
==29134== by 0x3167AB: ldap_int_sasl_bind (cyrus.c:801)<br>
==29134== <br>
==29134== Use of uninitialised value of size 4<br>
==29134== at 0x5F1936: k5_arcfour_init (rc4.c:110)<br>
==29134== by 0x5F1AAB: k5_arcfour_docrypt (rc4.c:150)<br>
==29134== by 0x76D332: kg_get_seq_num (util_seqnum.c:74)<br>
==29134== by 0x76D98C: kg_make_seq_num (val_cred.c:56)<br>
==29134== by 0x767BCC: rotate_left (string3.h:52)<br>
==29134== by 0x76B25E: krb5_gss_seal (set_allowable_enctypes.c:104)<br>
==29134== by 0x76A096: gss_krb5_get_tkt_flags (krb5_gss_glue.c:1035)<br>
==29134== by 0x75A739: gss_unseal (g_unseal.c:84)<br>
==29134== by 0x75A796: gss_unwrap (g_unseal.c:119)<br>
==29134== by 0x479F0B8: gssapi_client_mech_step (gssapi.c:1680)<br>
==29134== by 0x14468A: sasl_client_step (client.c:655)<br>
==29134== by 0x3167AB: ldap_int_sasl_bind (cyrus.c:801)<br>
==29134== <br>
==29134== Syscall param write(buf) points to uninitialised byte(s)<br>
==29134== at 0xC3DF73: __write_nocancel (in /lib/libc-2.8.so)<br>
==29134== by 0x1C83B1: sb_debug_write (sockbuf.c:852)<br>
==29134== by 0x1C8821: ber_int_sb_write (sockbuf.c:445)<br>
==29134== by 0x1C5F23: ber_flush2 (io.c:256)<br>
==29134== by 0x3242C8: ldap_int_flush_request (request.c:152)<br>
==29134== by 0x3246BE: ldap_send_server_request (request.c:348)<br>
==29134== by 0x3248A1: ldap_send_initial_request (request.c:136)<br>
==29134== by 0x318FB1: ldap_sasl_bind (sasl.c:148)<br>
==29134== by 0x319287: ldap_sasl_bind_s (sasl.c:182)<br>
==29134== by 0x316575: ldap_int_sasl_bind (cyrus.c:737)<br>
==29134== by 0x318A15: ldap_sasl_interactive_bind_s (sasl.c:464)<br>
==29134== by 0x804FF62: tool_bind (common.c:1336)<br>
==29134== Address 0x4048e3d is 53 bytes inside a block of size 4,060
alloc'd<br>
==29134== at 0x4006AEE: malloc (vg_replace_malloc.c:207)<br>
==29134== by 0x1C6F3F: ber_memalloc_x (memory.c:226)<br>
==29134== by 0x1C799B: ber_memrealloc_x (memory.c:304)<br>
==29134== by 0x1C6149: ber_realloc (io.c:155)<br>
==29134== by 0x1C6313: ber_write (io.c:114)<br>
==29134== by 0x1C3516: ber_put_tag (encode.c:100)<br>
==29134== by 0x1C3D7F: ber_put_int_or_enum (encode.c:284)<br>
==29134== by 0x1C4B25: ber_printf (encode.c:774)<br>
==29134== by 0x318F45: ldap_sasl_bind (sasl.c:122)<br>
==29134== by 0x319287: ldap_sasl_bind_s (sasl.c:182)<br>
==29134== by 0x316575: ldap_int_sasl_bind (cyrus.c:737)<br>
==29134== by 0x318A15: ldap_sasl_interactive_bind_s (sasl.c:464)<br>
<br>
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!<br>
<br>
Howard.<br>
</body>
</html>