==3252== Use of uninitialised value of size 8 ==3252== at 0x54FA8AB: _hc_rijndaelEncrypt (rijndael-alg-fst.c:961) ==3252== by 0x54EC45E: hc_AES_encrypt (aes.c:67) ==3252== by 0x54EC523: hc_AES_cbc_encrypt (aes.c:88) ==3252== by 0x55018A8: aes_do_cipher (evp-hcrypto.c:89) ==3252== by 0x55011C7: hc_EVP_Cipher (evp.c:967) ==3252== by 0x4B9F569: evp_encrypt_cts (crypto.c:2125) ==3252== by 0x4BA0C3C: encrypt_internal_derived (crypto.c:2956) ==3252== by 0x4BA2E14: krb5_encrypt_ivec (crypto.c:3864) ==3252== by 0x4BA2EE0: krb5_encrypt (crypto.c:3881) ==3252== by 0x294F784: _gssapi_wrap_cfx (cfx.c:1275) ==3252== by 0x294C888: _gsskrb5_wrap (wrap.c:550) ==3252== by 0x295EB90: gss_wrap (gss_wrap.c:53) ==3252== by 0x18AE5CB: gensec_gssapi_seal_packet (gensec_gssapi.c:974) ==3252== by 0x18A6722: gensec_seal_packet (gensec.c:860) ==3252== by 0x18999DD: gensec_spnego_seal_packet (spnego.c:148) ==3252== by 0x18A6722: gensec_seal_packet (gensec.c:860) ==3252== by 0x74F127D: dcesrv_auth_response (dcesrv_auth.c:466) ==3252== by 0x74EFEF8: dcesrv_reply (reply.c:226) ==3252== by 0x7541C65: dcesrv_request (dcerpc_server.c:979) ==3252== by 0x7542134: dcesrv_process_ncacn_packet (dcerpc_server.c:1108) ==3252== by 0x754309C: dcesrv_read_fragment_done (dcerpc_server.c:1486) ==3252== by 0x1D1F144: _tevent_req_notify_callback (tevent_req.c:95) ==3252== by 0x1D1F179: tevent_req_finish (tevent_req.c:104) ==3252== by 0x1D1F1A1: _tevent_req_done (tevent_req.c:110) ==3252== by 0x3A5314B: dcerpc_read_ncacn_packet_done (dcerpc_util.c:294) ==3252== by 0x1D1F144: _tevent_req_notify_callback (tevent_req.c:95) ==3252== by 0x1D1F179: tevent_req_finish (tevent_req.c:104) ==3252== by 0x1D1F1A1: _tevent_req_done (tevent_req.c:110) ==3252== by 0x4740C12: tstream_readv_pdu_ask_for_next_vector (tsocket_helpers.c:228) ==3252== by 0x4740DDB: tstream_readv_pdu_readv_done (tsocket_helpers.c:287) Andrew Bartlet suggest to add dump_data() just before the first call of non samba code (heimdal) and rerun valgrind. If valgrind cries then it's a 100% samba4 pb otherwise it's a heimdal
In order to reproduce: ../buildtools/bin/waf test --tests='samba4.rpc.lsa.on.ncacn_np.with.seal,padcheck' --valgrind-server --screen
Seems to be pb at samba side [0000] 00 00 00 00 34 00 00 C0 00 00 00 00 00 00 00 00 ....4... ........ [0000] 00 00 02 00 03 00 00 00 00 00 00 00 00 00 00 00 ........ ........ [0010] 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ........ ........ [0020] 00 00 00 00 00 00 00 00 2C 01 00 00 00 00 00 00 ........ ,....... [0030] ==22078== Use of uninitialised value of size 4 ==22078== at 0x520B888: _itoa_word (_itoa.c:196) ==22078== by 0x520F109: vfprintf (vfprintf.c:1613) ==22078== by 0x522FF36: vasprintf (vasprintf.c:64) ==22078== by 0x484ECEC: dbgtext (debug.c:127) ==22078== by 0x4855CB9: _dump_data (util.c:343) ==22078== by 0x4855F7F: dump_data (util.c:384) ==22078== by 0x4C49633: gensec_gssapi_seal_packet (gensec_gssapi.c:964) ==22078== by 0x4C4FCF1: gensec_seal_packet (gensec.c:860) ==22078== by 0x4C399DC: gensec_spnego_seal_packet (spnego.c:148) ==22078== by 0x4C4FCF1: gensec_seal_packet (gensec.c:860) ==22078== by 0x4ACD665: dcesrv_auth_response (dcesrv_auth.c:465) ==22078== by 0x4ACBA84: dcesrv_reply (dcerpc_server.c:1122) ==22078== by 0x4ACB7C1: dcesrv_request (dcerpc_server.c:1039)
Andrew, are you able to look at this? I tried to do some investigation but I'm not familiar with auth code.
Ekacnet, could this have been fixed by http://gitweb.samba.org/samba.git/?p=samba.git;a=commitdiff;h=5f655e99a1c17ac9d28acb4740585d2100746d69? Or do you still reproduce it?
It's probably an uninitialised out value in a call somewhere. Encryption often shows up these things, because it's the first thing to do anything other than print the value. It does not mean that the bug in the the crypto code.
I've managed to fix the bug - the patch is currently under autobuild and should appear in master (http://gitweb.samba.org/samba.git/?p=mdw/samba-autobuild/.git;a=commitdiff;h=d0b39324471e5226613a86aad313557cd4a89a9a).