TLDR: SBE may read freed memory after spilling, when there are concurrent catalog-changing operations.

Description of Bug
SBE is running a query, reading at a particular snapshot. A blocking stage then decides to spill. The spill operation performs a write and commits it in a separate WriteUnitOfWork under the same RecoveryUnit. After this write commits, our snapshot may advance. As part of advancing the snapshot, the CollectionCatalog shared_ptr decorating decorating the current Snapshot is destroyed.

Today SBE does not handle this situation, and assumes that the CollectionCatalog remains the same after the write, as it keeps pointers to the current Collection in the CollectionPtr objects it stores.

In the (unlikely) case where the spilling query's RecoveryUnit holds the last reference to the CollectionCatalog, (or the case where another thread destroys the CollectionCatalog immediately after the spill write commits), attempting to call CollectionPtr::yield() will result in a use-after-free, as the CollectionPtr will try to read the uuid of a deleted Collection object.

How to Fix it

• One option is to treat spills as "yield events." We save the plan's state before committing the spill write, and restore it afterwards. This way the plan is never holding onto pointers to a destroyed CollectionCatalog.
• Another option is to spill in a separate storage transaction. SERVER-61116 and SERVER-74133 discusses why this requires a some delicacy. It is possible to deadlock when using multiple WT sessions from the same thread.
• Don't spill to a temporary record store.
• Anything else.

Notes
As louis.williams@mongodb.com discussed in SERVER-74133, there are other problems with spilling to a temporary RecordStore, so we may want to deal with both of these issues at the same time.