Inadequate locking for multithreading in libModSecurity In-Memory persistent storage

This issue does not apply to the main, current use case of libModSecurity with nginx, since that is a multi-process but single-threaded application. This finding is based on code inspection only; I did not build a multi-threaded environment to prove a crash or other tangible errors.

While adding the expirevar support I noticed that, while the in-memory option includes some internal locking, it does so only for updates.

The problem is that if ThreadA is performing a read-only action using an interator and, while that is ongoing, ThreadB makes an update to the data, it could invalidate the iterator that ThreadA is in the midst of using. (Note that the update by ThreadB might be a deletion, but an insertion could also invalidate the iterator that is in-use by ThreadA.)

The issue names no files or tests; start by locating the libModSecurity in-memory persistent-storage implementation and its iterator read and update paths. Review the existing update locking and verify that concurrent iterator reads and insertions or deletions cannot invalidate active iteration, then add or run a multithreaded test if the project provides one.