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. - or should X509_NAME_dup() be made mt-safe, e.g. by introducing a lock regards Beat ______________________________________________________________________ OpenSSL Project http://www.openssl.org Development Mailing List [email protected] Automated List Manager [EMAIL PROTECTED]
