Beat Zimmermann wrote:
Hi
we have experienced a reproducible race condition when calling
X509_NAME_dup
which leads to corrupt asn1 data. Corresponding error messages were:
ASN1_CHECK_TLEN: wrong tag
ASN1_TEMPLATE_NOEXP_D2I: unexpected eoc
Our usage pattern:
1) we create a new x509 name (protected by lock) by calling
- newName = X509_NAME_new()
- callAddEntryByObj(newName, ....)
2) then multiple threads concurrently try to get a copy of the new name
by calling X509_NAME_dup() on it
Problem:
after step 1 newName is in 'modified' state, meaning that encoding must
be done.
This encoding is done lazily within X509_NAME_dup.
Since encoding is not protected by mutex, multiple threads may do it
concurrently.
Workaround:
we enforce encoding of newName after its creation by calling
i2d_X509_NAME().
Thus we avoid lazy encoding within X509_NAME_dup().
Questions:
- is our usage pattern a known anti-pattern? Then it should be
documented somewhere.
well, the X509_NAME parameter in X509_NAME_dup() isn't const so
you can't really assume that multiple threads could use the same
object concurrently. On the other hand is it somewhat unfortunate
that a foo_dup() functions doesn't have a const parameter as
everyone would normally expect ...
I guess this behaviour should be documented somewhere.
Cheers,
Nils
______________________________________________________________________
OpenSSL Project http://www.openssl.org
Development Mailing List openssl-dev@openssl.org
Automated List Manager [EMAIL PROTECTED]
