From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; rv:1.7.3) Gecko/20041020
Firefox/0.10.1

Description of problem:
I came across this problem while investigating a possible hack-around
for bug #143147 and I found a similar bug for RH7 (bug #66053, dating
back two and a half years and still new and uncommented).

This problem has several aspects, but I'll describe just one that
actually happens.

The call sasl_set_alloc() is used to set allocation routines instead
of the default.  The ldap client libraries use this to replace the
default allocation routines with the allocation routines used by,
among other things, the lber routines.

If server that uses SASL for authentication, say, calls attempts to
use the ldap routines while in the midst of a SASL authentication
sequence it will crash.  This is not only easy to achieve, it's
practically unavoidable.   If you have a SASL_CB_CANON_USER callback
that looks up the user in an LDAP directory then the SASL allocation
routines will change half way through the SASL authentication
sequence.   It's not so much the malloc(), calloc() and realloc()
routines changing under your feet as the free() routine changing. 
Once the ldap routines have called and the SASL conversation finishes
and starts freeing up allocated storage.  Well, I don't have to paint
a picture do I? Sooner or later storage allocated with malloc() is
going to be freed with the lber free routine.  Boom!


Version-Release number of selected component (if applicable):
cyrus-sasl-2.1.*

How reproducible:
Sometimes

Steps to Reproduce:
See description.   It's not guaranteed to crash every time, but
valgrind usually spots the corruption.
    

Actual Results:  Core dump, often.

Expected Results:  The cyrus-sasl sasl_set_alloc() and
sasl_set_mutex() routines (and, I think, some of the hooks used
internally) are not re-entrant so nested implicit calls will tend to
produce unexpected and sometimes disasterous results.  See above.

Additional info:

There is a deeply unpleasnt workaround for this.  In the particular
case above I simply saved _sasl_allocation_utils (a cyrus-sasl private
variable) while I made the ldap calls and restored is afterwards. 
This workaround is OK for cyrus-sasl-1 and cyrus-sasl-2 and even a
combination :-)   Finding the right workaround, however, requires a
detailed source-level analysis of the application, cyrus-sasl and the
openldap client libraries.  With other combinations you'll need a
similar lengthy analysis.

The proper fix for this is is to have a new SASL context (in addition
to the client or server authentication context) to hold all this
global data.   This can be made a backwards compatible change so that
the existing sasl routines use a default global context and new ones
take a context as an extra parameter.   Code can be migrated to the
new interface as and when needed or convenient.

It's a bit of a mess though.