https://bugs.openldap.org/show_bug.cgi?id=10058

Issue ID: 10058 Summary: destroying robust mutexes leads to use of an uninitialized mutex Product: LMDB Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: liblmdb Assignee: bugs@openldap.org Reporter: jiri.novosad@gmail.com Target Milestone: ---

Created attachment 966 --> https://bugs.openldap.org/attachment.cgi?id=966&action=edit an example program to reproduce the bug

This is a regression introduced in https://bugs.openldap.org/show_bug.cgi?id=9278 .

The issue is that mdb_env_setup_locks initializes the mutex only when it gets an exclusive fcntl file lock. But there is this possible order of operations:

1. Process A opens the DB, gets an exclusive file lock, initializes the mutex, downgrades the file lock to shared and does its thing 2. Process A closes the env: it gets an exclusive lock and destroys the mutex 3. Process B opens the DB and blocks in mdb_env_excl_lock trying to get the shared lock 4. Process A finishes closing the env, closes the file descriptor and loses the file lock 5. Process B gets the shared lock, does not initialize the mutex in mdb_env_setup_locks (because it does not have the exclusive lock) 6. Process B tries to lock the mutex, but it is not initialized, pthread_mutex_lock returns EINVAL