Bug#534699: libssl0.9.8: likely race condition in int_new_ex_data()
On 2009-06-26 23:26:34 [+1000], Russell Coker wrote: > ==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. Does this still apply to 1.1.0c? The way the code looks now nothing should vanish out of the sudden. Sebastian
Bug#534699: libssl0.9.8: likely race condition in int_new_ex_data()
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. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org