doug.leavitt@oracle.com wrote:

Full_Name: Doug Leavitt Version: 2.4.44 OS: Solaris URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (137.254.4.13)

There is a race condition in ldap_int_utils_init that can be triggered when multiple threads enter ldap_int_utils_init from ldap_init_initialize about the same time. The done flag gets set immediately, before the various mutexes are initialized. If thread A sets done, and thread B tests for done==1 before thread A has completed the mutex inits, thread B can attempt to use an uninitialized mutex and fail/core dump etc.

Additionally if judt the done=1 is moved to the bottom of the function thwo threads can both be initializing the same mutexes multiple times causes other mayhem.

The short term workaround for Solaris (THR APIs) is to move setting of done=1 to after the mutex inits, and to protect the mutex inits using another statically initialized mutex within ldap_int_utils_init.

I know a similar workaround could be made for POSIX threads and possibly some of the other supported thread models, but this approach seems kludgely.

Static initializers would be the simplest fix, certainly. On Windows we'd have to use something similar to pthread_once() for initialization, instead.

I suspect the correct solution may be to somehow refactor ldap_int_utils_init out of libldap and into libldap_r in a cleaner multi-platform manner than the example above.