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.

__________________________________________________ ____________________
OpenSSL Project
Development Mailing List
Automated List Manager