We fix all leaks in asteris and libsrtp.... many calls have one leak path ==44910== Use of uninitialised value of size 8 ==44910== at 0x4A08DEF: memcpy (mc_replace_strmem.c:882) ==44910== by 0x38E3EFD266: c2i_ASN1_INTEGER (string3.h:52) ==44910== by 0x38E3F08823: asn1_ex_c2i (tasn_dec.c:992) ==44910== by 0x38E3F0929A: asn1_d2i_ex_primitive (tasn_dec.c:907) ==44910== by 0x38E3F09A61: ASN1_item_ex_d2i (tasn_dec.c:233) ==44910== by 0x38E3F0A683: ASN1_item_d2i (tasn_dec.c:136) ==44910== by 0x38E424D421: d2i_SSL_SESSION (ssl_asn1.c:395) ==44910== by 0x38E4232324: tls_decrypt_ticket (t1_lib.c:2235) ==44910== by 0x38E423251B: tls1_process_ticket (t1_lib.c:2124) ==44910== by 0x38E42474DC: ssl_get_prev_session (ssl_sess.c:482) ==44910== by 0x38E421F94E: ssl3_get_client_hello (s3_srvr.c:1017) ==44910== by 0x38E42222FC: ssl3_accept (s3_srvr.c:357) ==44910== Uninitialised value was created by a stack allocation ==44910== at 0x38E3E90077: aesni_cbc_encrypt (aesni-x86_64.s:2149)
==44910== Conditional jump or move depends on uninitialised value(s) ==44910== at 0x4A08DF1: memcpy (mc_replace_strmem.c:882) ==44910== by 0x38E3EFD266: c2i_ASN1_INTEGER (string3.h:52) ==44910== by 0x38E3F08823: asn1_ex_c2i (tasn_dec.c:992) ==44910== by 0x38E3F0929A: asn1_d2i_ex_primitive (tasn_dec.c:907) ==44910== by 0x38E3F09A61: ASN1_item_ex_d2i (tasn_dec.c:233) ==44910== by 0x38E3F0A683: ASN1_item_d2i (tasn_dec.c:136) ==44910== by 0x38E424D421: d2i_SSL_SESSION (ssl_asn1.c:395) ==44910== by 0x38E4232324: tls_decrypt_ticket (t1_lib.c:2235) ==44910== by 0x38E423251B: tls1_process_ticket (t1_lib.c:2124) ==44910== by 0x38E42474DC: ssl_get_prev_session (ssl_sess.c:482) ==44910== by 0x38E421F94E: ssl3_get_client_hello (s3_srvr.c:1017) ==44910== by 0x38E42222FC: ssl3_accept (s3_srvr.c:357) ==44910== Uninitialised value was created by a stack allocation ==44910== at 0x38E3E90077: aesni_cbc_encrypt (aesni-x86_64.s:2149) 2014-11-13 2:58 GMT+03:00 Matt Caswell via RT <[email protected]>: > On Thu Nov 06 10:38:23 2014, [email protected] wrote: > > HI all > > > > CentOS x86_64 release 6.6 (Final) > > > > OpenSSL> version > > OpenSSL 1.0.1e-fips 11 Feb 2013 > > > > # rpm -qa | grep openssl > > openssl-devel-1.0.1e-30.el6_6.2.x86_64 > > openssl-debuginfo-1.0.1e-30.el6_6.2.x86_64 > > openssl-1.0.1e-30.el6_6.2.x86_64 > > > > > > Please look to > > https://issues.asterisk.org/jira/browse/ASTERISK-24472 > > > > Again bug in DTLS in OpenSSL? > > Hmmm...tricky. > > The crashes you are seeing appear to occur in a number of different places > rather than the same place everytime. This might suggest some kind of > memory > issues?? The valgrind output is showing some significant problems...some of > which seem to be in OpenSSL and some of which seem to be in your > application. > You should focus on trying to resolve those. The OpenSSL issues seem to be > largely (but not exclusively) occuring in the handling of session tickets. > I've > run some tests locally with session tickets using valgrind and > s_server/s_client, and valgrind is not reporting any problems. > > Is it possible for you to use standard OpenSSL rather than rpms for further > testing? Ideally you should use the latest standard 1.0.1 version, as there > have been a number of DTLS related issues that have been fixed in recent > months. Also can you rerun the valgrind tests having ensured that you > configure > OpenSSL with -DPURIFY. Without that defined you will get false positives > reported from valgrind. The version that you are using is also quite > difficult > to track against the source because it (probably) has some distro specific > patches so line numbers are not matching up. It would also be useful to run > valgrind with --track-origins=yes > > Matt > > -- С уважением, Бадалян Вячеслав Борисович ООО "Открытые бизнес-решения" Технический директор +7 (495) 666-0-111 http://www.open-bs.ru ______________________________________________________________________ OpenSSL Project http://www.openssl.org Development Mailing List [email protected] Automated List Manager [email protected]
