The LDAP connection pool enforces timeouts by setting an alarm on one thread, performing the bind on another, and having them race against each other to set the return value to the caller. If the alarm wins the race, then the caller receives a timeout error from the alarm thread, unblocks, and propagates the error. However, the thread performing the bind continues working asynchronously, and it receives the bind options from the caller by reference. As a result, the server may see undefined behavior from the system LDAP library accessing the bind options after the timeout.

The server should strictly scope the lifetime of the bind options such that they remain in scope as long as any active connection in the pool is still consuming them, irrespective of whether or not the connection has been timed out.