Bug#534699: libssl0.9.8: likely race condition in int_new_ex_data()

2017-01-07 Thread Sebastian Andrzej Siewior 
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()

2009-06-26 Thread Russell Coker 
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