[SERVER-44368] Client lock must protect OperationContext's LockState pointer Created: 01/Nov/19 Updated: 29/Oct/23 Resolved: 04/Nov/19 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | Internal Code |
| Affects Version/s: | None |
| Fix Version/s: | 4.3.1 |
| Type: | Bug | Priority: | Major - P3 |
| Reporter: | Eric Milkie | Assignee: | Eric Milkie |
| Resolution: | Fixed | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||||||||||
| Backwards Compatibility: | Fully Compatible | ||||||||||||
| Operating System: | ALL | ||||||||||||
| Sprint: | Execution Team 2019-11-04 | ||||||||||||
| Participants: | |||||||||||||
| Linked BF Score: | 56 | ||||||||||||
| Description |
|
The GlobalLockServerStatusSection assumes that it can lock a Client's mutex and then call this function on that Client: However, we routinely swap out or change the lock state pointer in an OperationContext without locking the mutex. This can cause the server status section code to hit a null pointer, or read freed memory. The fix should be to ensure that the Client mutex is locked before touching an OperationContext's _locker member. Currently, there are two member functions that do this: setLockState() and swapLockState(). |
| Comments |
| Comment by Githook User [ 04/Nov/19 ] |
|
Author: {'username': 'milkie', 'email': 'milkie@mongodb.com', 'name': 'Eric Milkie'}Message: |