https://bugs.openldap.org/show_bug.cgi?id=10258
--- Comment #1 from Ondřej Kuzník ondra@mistotebe.net --- Correlating the logs with the code, this seems to be the sequence of events: - client sends an Unbind - slapd_daemon_task in thread A (0x7fc2738396c0) picks up fd=9 (conn=1004), calls slapd_clr_read and submits connection_read_thread to the queue - a worker thread B (0x7fc270c2c6c0) runs connection_read_thread->connection_read, reads one operation (unbind) queues it up in cri->op, then calls slapd_set_read - only the unbind was read, so it is immediately processed in the same worker thread B (B side of the race) - client closes the connection - slapd_daemon_task in thread A notices and picks up fd=9 again (A side of the race) - worker thread B wins the race and calls connection_closing resetting the epoll state - daemon A lost the race and will reach SLAP_EPOLL_SOCK_SET. Using invalid epoll state (which is now pointing to offset -1) it reaches memory that's not intended for this purpose (presumably not even allocated) and address sanitiser intervenes