Your message dated Mon, 9 Jan 2017 22:32:13 +0100 with message-id <[email protected]> and subject line Re: libssl0.9.8: int_free_ex_data() is reported as having a race condition has caused the Debian Bug report #534889, regarding libssl0.9.8: int_free_ex_data() is reported as having a race condition to be marked as done.
This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what this message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact [email protected] immediately.) -- 534889: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=534889 Debian Bug Tracking System Contact [email protected] with problems
--- Begin Message ---Package: libssl0.9.8 Version: 0.9.8g-15+lenny1 Severity: normal ==6373== Possible data race during read of size 8 at 0x6d2ad28 by thread #4 ==6373== at 0x52D1242: int_free_ex_data (ex_data.c:497) ==6373== by 0x5318A9D: RSA_free (rsa_lib.c:225) ==6373== by 0x533A200: EVP_PKEY_free (p_lib.c:479) ==6373== by 0x40DDDE: SelectorInfo::~SelectorInfo() (dkimverify.cpp:1189) ==6373== by 0x410946: CDKIMVerify::~CDKIMVerify() (new_allocator.h:118) ==6373== by 0x4077D7: DKIMVerifyFree (dkim.cpp:223) Above is the helgrind output from a test run on an AMD64 system. if((item = def_get_class(class_index)) == NULL) return; CRYPTO_r_lock(CRYPTO_LOCK_EX_DATA); mx = sk_CRYPTO_EX_DATA_FUNCS_num(item->meth); The last line of the above code segment is ex_data.c:497. Maybe if we obtained a suitable lock before calling def_get_class() then this would be OK.
--- End Message ---
--- Begin Message ---On 2009-06-28 09:39:50 [+1000], Russell Coker wrote: > Package: libssl0.9.8 > Version: 0.9.8g-15+lenny1 > Severity: normal > > ==6373== Possible data race during read of size 8 at 0x6d2ad28 by thread #4 > ==6373== at 0x52D1242: int_free_ex_data (ex_data.c:497) > ==6373== by 0x5318A9D: RSA_free (rsa_lib.c:225) > ==6373== by 0x533A200: EVP_PKEY_free (p_lib.c:479) > ==6373== by 0x40DDDE: SelectorInfo::~SelectorInfo() (dkimverify.cpp:1189) > ==6373== by 0x410946: CDKIMVerify::~CDKIMVerify() (new_allocator.h:118) > ==6373== by 0x4077D7: DKIMVerifyFree (dkim.cpp:223) > > Above is the helgrind output from a test run on an AMD64 system. > > if((item = def_get_class(class_index)) == NULL) > return; > CRYPTO_r_lock(CRYPTO_LOCK_EX_DATA); > mx = sk_CRYPTO_EX_DATA_FUNCS_num(item->meth); > > The last line of the above code segment is ex_data.c:497. Maybe if we > obtained > a suitable lock before calling def_get_class() then this would be OK. as stated in other reports which were similar to this one: code changed and its current usage (in the class code) looks / is valid. Sebastian
--- End Message ---
