On Sun Jul 10 19:38:03 2016, ms...@barracuda.com wrote: > OpenSSL 1.0.2h > > The function eckey_priv_encode() may crash if the same pkey is > serialized from multiple threads. Here is a sample backtrace: > > #0 0x00007fff8f321f92 in _platform_memmove$VARIANT$Haswell () > #1 0x0000000100196132 in i2c_ASN1_BIT_STRING > #2 0x00000001001a1fb2 in asn1_ex_i2c > #3 0x00000001001a1e68 in asn1_i2d_ex_primitive > #4 0x00000001001a19fd in ASN1_item_ex_i2d > #5 0x00000001001a1d8b in asn1_template_ex_i2d > #6 0x00000001001a1a8b in ASN1_item_ex_i2d > #7 0x00000001001a16d0 in asn1_item_flags_i2d > #8 0x0000000100149d3e in i2d_ECPrivateKey > #9 0x000000010014e576 in eckey_priv_encode > #10 0x000000010018e9f9 in EVP_PKEY2PKCS8_broken > #11 0x00000001001d38d9 in PKCS12_add_key > #12 0x00000001001d35a3 in PKCS12_create > > EC_KEY_set_enc_flags() is called to modify/restore the encoding flags > within the EC_KEY. Two calls are made to i2d_ECPrivateKey(). The first > calculates the necessary buffer length, the second serializes the data > into an allocated buffer. If the flags change during this period, the > second call overwrites the buffer. > > These APIs are documented as thread safe, and should not change the > internal flags of the pkey without proper locking.
Problem fixed in upcoming 1.1.0 and 1.0.2 releases. The issue was actually that the input EC_KEY was modified at all. The code has been modified to take a temporary shallow copy of the input EC_KEY and modify the copy instead. Relevant commits are: b8a7bd83e68405fdf595077973035ac6fe24cb97 (master branch) 427b22646d4642809f67352513590549650b916f (1.0.2 branch) Closing this ticket. Cheers, Richard -- Richard Levitte levi...@openssl.org -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4611 Please log in as guest with password guest if prompted -- openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev