-
Type: Bug
-
Resolution: Fixed
-
Priority: Major - P3
-
Affects Version/s: None
-
Component/s: Internal Code
-
Fully Compatible
-
ALL
-
v5.0
-
Service Arch 2022-1-24, Service Arch 2022-2-07
-
113
-
2
Attempting to close SSL sockets through ASIOSession::end() is not multi-thread safe. Here is a possible scenario where we can have a read after write data-race:
- Thread 1 is running SSL handshake, and attempts to emplace the established SSL socket into _sslSocket (see here). This is done while holding the session lock.
- Thread 2 calls into ASIOSession::end(), which will attempt to get the underlying socket object by inquiring _sslSocket multiple times (here). All these accesses are done without holding the lock.
We can serialize accesses to _sslSocket by threads calling into ASIOSession::end() and ASIOSession::handshakeSSLForEgressWithLock() using a mutex. This should ensure the socket is not altered while running ASIOSession::end().
- is related to
-
SERVER-54900 Blocking networking calls can delay sync-source resolution indefinitely
- Closed
- related to
-
SERVER-62970 Separate SSL socket construction from handshake
- Closed