-
Notifications
You must be signed in to change notification settings - Fork 1.5k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Inadequate locking for multithreading in libModSecurity In-Memory persistent storage #3054
Comments
Hi @martinhsv, thanks for sharing the results of your inspection. I try to write a sample code that will help us to investigate the behavior that you explained, but it would be a help if you could provide a rule set which helps to cause the (possible) behavior? |
Hi @martinhsv, thanks again for your report. I made a small test source which embeds the libmodsecurity3 library to a multi threaded application. The sad news is that it not necessary to add the If the debug log is turned on, it is guaranteed to cause a segfault.
If I turn off the debug.log, then I got a segfault in
I'm going to finish that example tool soon (add the correct |
Yes of course. I never claimed that the problem originated with that 2023 development effort, only that that was when I noticed it. The underlying issue has been present in the code for years. |
There is a separated branch which has a new, multi-threaded example. With this, I couldn't reproduce this behavior. @martinhsv please take a look to rules - is that something you thought? If anyone wants to play with that code, please let me know, I try to help. |
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 text was updated successfully, but these errors were encountered: