[SERVER-56900] SBE sort stage may violate SBE copyOrMove contract Created: 12/May/21  Updated: 27/Oct/23  Resolved: 17/May/21

Status: Closed
Project: Core Server
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Major - P3
Reporter: Ian Boros Assignee: Ian Boros
Resolution: Gone away Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Depends
is depended on by SERVER-52799 Make sbe the default execution engine... Closed
Related
related to SERVER-56869 [SBE][ASAN jscore] heap-use-after-fre... Closed
Operating System: ALL
Sprint: Query Execution 2021-05-17, Query Execution 2021-05-31
Participants:

 Description   

This code assumes that 'keys' and 'values' get moved into the sorter. However, not all implementations of the sorter's emplace() method actually move from the passed in key. See here for example.

 

Consider the following scenario:

1) the sort stage is opened, and calls getNext() on its child. It calls copyOrMove() on its inAccessors, moving ownership to local variables 'keys' and 'vals'. Keep in mind that SBE "move" is non-destructive, unlike a C++ std::move(). So the inAccessors still point to the same values, just their 'owned' flag is now false.

2) The call to emplace() is made to an overload which does not move from the arguments.

3) The local variables 'keys' and 'vals' go out of scope. The underlying memory is freed. Now the inAccessors are pointing to garbage.



 Comments   
Comment by Ian Boros [ 17/May/21 ]

This was fixed under SERVER-56869.

Comment by Ian Boros [ 17/May/21 ]

I have a fix for this lumped into the patch for SERVER-56869. This will be closed as "gone away" once that is merged.

Generated at Thu Feb 08 05:40:29 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.