Re: (ITS#8450) race condition in ldap_int_utils_init

[hyc@symas.com]

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.
>
>


-- 
   -- Howard Chu
   CTO, Symas Corp.           http://www.symas.com
   Director, Highland Sun     http://highlandsun.com/hyc/
   Chief Architect, OpenLDAP  http://www.openldap.org/project/