[SERVER-48534] NetworkTestEnv should not schedule responses for fire-and-forget commands Created: 02/Jun/20 Updated: 29/Oct/23 Resolved: 03/Jun/20 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | Sharding, Testing Infrastructure |
| Affects Version/s: | None |
| Fix Version/s: | 4.7.0 |
| Type: | Improvement | Priority: | Major - P3 |
| Reporter: | Kevin Pulo | Assignee: | Kevin Pulo |
| Resolution: | Fixed | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||||||
| Backwards Compatibility: | Fully Compatible | ||||||||
| Sprint: | Sharding 2020-06-15 | ||||||||
| Participants: | |||||||||
| Description |
|
This is a problem because when some code (such as the establishCursors clean-up thread) sends a fire-and-forget command, it doesn't wait for the response (by definition). This means that the opCtx and Client used by the request might be de-allocated immediately after the command was sent. However, NetworkTestEnv may still schedule a response for the command (if the test author defines what the command ought to return, which is not unreasonable despite the command being fire-and-forget). This leads to the potentially-freed opCtx being passed to readReplyMetadata(). If any metadata hooks use the opCtx, it can result in a use-after-free. (Currently no metadata hooks actually do this, but that is being changed by |
| Comments |
| Comment by Githook User [ 03/Jun/20 ] |
|
Author: {'name': 'Kevin Pulo', 'email': 'kevin.pulo@mongodb.com', 'username': 'devkev'}Message: |