Your message dated Mon, 9 Jan 2017 22:29:13 +0100 with message-id <[email protected]> and subject line Re: Bug#534687: libssl0.9.8: lh_retrieve modifies global data, bug in valgrind or OpenSSL? has caused the Debian Bug report #534699, regarding libssl0.9.8: likely race condition in int_new_ex_data() 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.) -- 534699: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=534699 Debian Bug Tracking System Contact [email protected] with problems
--- Begin Message ---Package: libssl0.9.8 Version: 0.9.8g-15+lenny1 Severity: normal ==28314== Possible data race during read of size 8 at 0x6535338 by thread #3 ==28314== at 0x52D183B: int_new_ex_data (ex_data.c:410) ==28314== by 0x5318BD7: RSA_new_method (rsa_lib.c:185) ==28314== by 0x531B76C: rsa_cb (rsa_asn1.c:80) ==28314== by 0x534CB42: asn1_item_ex_combine_new (tasn_new.c:177) ==28314== by 0x53501E4: ASN1_item_ex_d2i (tasn_dec.c:399) ==28314== by 0x53502B3: ASN1_item_d2i (tasn_dec.c:134) ==28314== by 0x534863C: d2i_PublicKey (d2i_pu.c:96) ==28314== by 0x534624F: X509_PUBKEY_get (x_pubkey.c:364) ==28314== by 0x5346C07: d2i_PUBKEY (x_pubkey.c:390) ==28314== by 0x40D480: SelectorInfo::Parse(char*) (dkimverify.cpp:1312) ==28314== by 0x40E0A4: CDKIMVerify::GetSelector(std::string const&, std::string const&) (dkimverify.cpp:1369) I get the above from helgrind on my AMD64 system. EX_CLASS_ITEM *item = def_get_class(class_index); if(!item) /* error is already set */ return 0; ad->sk = NULL; CRYPTO_r_lock(CRYPTO_LOCK_EX_DATA); mx = sk_CRYPTO_EX_DATA_FUNCS_num(item->meth); // line 410 Above is the relevant section of int_new_ex_data(). The def_get_class() function calls CRYPTO_w_lock(CRYPTO_LOCK_EX_DATA); before returning a pointer to a member of the hash table. Now it seems possible for the item to be deleted from the hash table after def_get_class() is called but before CRYPTO_r_lock(CRYPTO_LOCK_EX_DATA) is called.
--- End Message ---
--- Begin Message ---On 2017-01-08 12:06:12 [+1100], Russell Coker wrote: > On Saturday, 7 January 2017 10:23:56 PM AEDT Sebastian Andrzej Siewior wrote: > > I am tempted to close this. Can you still reproduce this with current > > openssl & valgrind? RSA_new_method() is no longer using the class thingy > > / lhash so your old testcase won't do. And then 1.1.0c is using > > pthread's locking functions so valgrind should know by now when a lock > > is held. > > Yes close these ancient bugs. Assuming this counts for #534534 and #534699, too. Sebastian
--- End Message ---
