Hi core team,
On 4th October I submitted a patch to crypto/rsa/rsa_eay.c to fix some
multithreaded race conditions. Nobody replied to my message at the time,
and I've just noticed that the latest snapshot doesn't include these fixes.
Did this just get overlooked, or was it purposely rejected? If rejected,
could you please let me know the reason so that I can address it, as these
are real bugs still present on the HEAD.
I've appended the original message to this email.
Regards,
Steven
--
Steven Reddie <[EMAIL PROTECTED]>
Senior Software Engineer
OpenDirectory Lab, Computer Associates Pty Ltd (Australia)
I've come across four race conditions in the following functions in
rsa_eay.c:
RSA_public_encrypt
RSA_public_decrypt
RSA_eay_mod_exp (x2)
These can cause unexpected failure of the RSA_eay_ encryption/decryption
functions for both public and private key operations. The problem occurs
when more than one thread simultaneously uses the same RSA key (more
specifically, when multiple threads simultaneously initialise
rsa->_method_mod_[npq] when RSA_FLAG_CACHE_PUBLIC is set). The problems are
only easily reproduceable on a multi-processor machine, although they can
also occur on a single processor machine.
I've attached a patch for OpenSSL 0.9.6, though I've only tested it on
0.9.5a. The patch uses CRYPTO_LOCK_RSA, but perhaps it should be rewritten
to use the dyn_locks added in 0.9.5b. In order to not add overhead to the
non-initialisation run through the function, I test _method_mod_[npq], then
lock if it is NULL, then test again (since after aquiring the lock
_method_mod_[npq] may have been set).
<<openssl-0.9.6-rsa-mt.diff>>
openssl-0.9.6-rsa-mt.diff
