|
From: Howard W. <ho...@co...> - 2008-12-09 08:26:18
Attachments:
rc4.c
|
I am trying to track down a failure in my version of the nss_Ldap code and have been using valgrind 3.3.0/3.3.1 on Fedora 9 running memcheck with leak-check=full to assist in this. I am getting problems reported in the kerberos code but cannot see why they are being reported could anybody throw some light on this. I attach my modified version of rc4.c which shows these errors, as does the release version from krb5-1.6.3. My mods have been done to remove some additional variables and to ensure that the memory passed into the k5_arcfour_init routine are all pre-initialised. We see 2 problems: first the use of uninitialised memory being reported cannot be explained, but also the first reported sequence happens 4 times when there is only 2 iterations of the loop it falls within. Although there are 2 calls of the routine which may explain this. (See error report 1 below). We then get a single report of an error on lines inside a loop that iterates 256 times over data that has been initialised in code just above the loop. BUT this is only reported once (hence in the second call to the routine) See error report 2 below. Any ideas? Howard. ==13190== Conditional jump or move depends on uninitialised value(s) ==13190== at 0x5448BA: k5_arcfour_init (rc4.c:95) ==13190== by 0x544AF8: k5_arcfour_docrypt (rc4.c:152) ==13190== by 0x629162: kg_get_seq_num (util_seqnum.c:74) ==13190== by 0x6297BC: kg_make_seq_num (val_cred.c:56) ==13190== by 0x6239CC: rotate_left (string3.h:59) ==13190== by 0x62705E: krb5_gss_seal (set_allowable_enctypes.c:98) ==13190== by 0x625E96: gss_krb5_get_tkt_flags (krb5_gss_glue.c:1031) ==13190== by 0x616539: gss_unseal (g_unseal.c:83) ==13190== by 0x616596: gss_unwrap (g_unseal.c:118) ==13190== by 0x486D0B8: gssapi_client_mech_step (gssapi.c:1680) ==13190== by 0x14468A: sasl_client_step (client.c:655) ==13190== by 0x4691CDB: ldap_int_sasl_bind (in /usr/lib/libnss_ldap-264.so) ==13190== Use of uninitialised value of size 4 ==13190== at 0x544933: k5_arcfour_init (rc4.c:110) ==13190== by 0x544AF8: k5_arcfour_docrypt (rc4.c:152) ==13190== by 0x629162: kg_get_seq_num (util_seqnum.c:74) ==13190== by 0x6297BC: kg_make_seq_num (val_cred.c:56) ==13190== by 0x6239CC: rotate_left (string3.h:59) ==13190== by 0x62705E: krb5_gss_seal (set_allowable_enctypes.c:98) ==13190== by 0x625E96: gss_krb5_get_tkt_flags (krb5_gss_glue.c:1031) ==13190== by 0x616539: gss_unseal (g_unseal.c:83) ==13190== by 0x616596: gss_unwrap (g_unseal.c:118) ==13190== by 0x486D0B8: gssapi_client_mech_step (gssapi.c:1680) ==13190== by 0x14468A: sasl_client_step (client.c:655) ==13190== by 0x4691CDB: ldap_int_sasl_bind (in /usr/lib/libnss_ldap-264.so) ==13190== ==13190== Use of uninitialised value of size 4 ==13190== at 0x54493E: k5_arcfour_init (rc4.c:111) ==13190== by 0x544AF8: k5_arcfour_docrypt (rc4.c:152) ==13190== by 0x629162: kg_get_seq_num (util_seqnum.c:74) ==13190== by 0x6297BC: kg_make_seq_num (val_cred.c:56) ==13190== by 0x6239CC: rotate_left (string3.h:59) ==13190== by 0x62705E: krb5_gss_seal (set_allowable_enctypes.c:98) ==13190== by 0x625E96: gss_krb5_get_tkt_flags (krb5_gss_glue.c:1031) ==13190== by 0x616539: gss_unseal (g_unseal.c:83) ==13190== by 0x616596: gss_unwrap (g_unseal.c:118) ==13190== by 0x486D0B8: gssapi_client_mech_step (gssapi.c:1680) ==13190== by 0x14468A: sasl_client_step (client.c:655) ==13190== by 0x4691CDB: ldap_int_sasl_bind (in /usr/lib/libnss_ldap-264.so) ==13190== |
|
From: Julian S. <js...@ac...> - 2008-12-09 08:42:29
|
> We see 2 problems: first the use of uninitialised memory being reported > cannot be explained, Check out and build the latest Valgrind sources, as described at http://valgrind.org/downloads/repository.html, and use the new --track-origins=yes flag. This gives a pretty good chance of telling you where the uninitialised values originally came from. J |