Fix use-after-free in moveForSlabRelease chained item path

Summary:
Investigation doc: https://fburl.com/gdoc/oxsftkii

Fix a use-after-free race condition in `CacheAllocator::moveForSlabRelease()`
for chained items. After `parentItem->unmarkMoving()`, another thread can
evict and free the parent item's memory. The subsequent calls to
`findInternal(parentKey)` and `wakeUpWaiters(parentItem->getKey(), ...)`
would then read freed memory through the dangling `Key` (which is a
`folly::StringPiece` — a non-owning view into the item's data buffer).

If the freed memory is reused with different content, `wakeUpWaiters` fails
to find the MoveCtx entry in the MoveMap (hash/equality mismatch on garbage
bytes), leaving the waiter's Baton permanently unposted. This causes threads
blocked on `ItemWaitContext::wait()` to deadlock indefinitely.

The fix copies the parent key to an owning `std::string` before calling
`unmarkMoving()`, ensuring all subsequent key uses reference valid memory.

Also fixes a typo: "Parnet" → "Parent" in a comment.

Reviewed By: stuclar, AlnisM

Differential Revision: D98565055

fbshipit-source-id: ea88bd4fbeaa4fc7cd992eca06af549b99633d30

Author: Lenar Fatikhov

cachelib/allocator/CacheAllocator.h

@@ -5216,26 +5216,31 @@ bool CacheAllocator<CacheTrait>::moveForSlabRelease(Item& oldItem) {
   const auto allocInfo = allocator_->getAllocInfo(oldItem.getMemory());
   if (chainedItem) {
     newItemHdl.reset();
-    auto parentKey = parentItem->getKey();
+    // Copy the parent key before unmarkMoving because once we unmark,
+    // another thread is free to remove/evict and free the parent item,
+    // which would make parentItem->getKey() a dangling StringPiece.
+    std::string parentKey(parentItem->getKey().data(),
+                          parentItem->getKey().size());
+    const auto parentKeyView = Key{folly::StringPiece{parentKey}};
     parentItem->unmarkMoving();
     // We do another lookup here because once we unmark moving, another thread
     // is free to remove/evict the parent item. So its unsafe to increment
     // refcount on the parent item's memory. Instead we rely on a proper lookup.
-    auto parentHdl = findInternal(parentKey);
+    auto parentHdl = findInternal(parentKeyView);
     if (!parentHdl) {
       // Parent is gone, so we wake up waiting threads with a null handle.
-      wakeUpWaiters(parentItem->getKey(), {});
+      wakeUpWaiters(parentKeyView, {});
     } else {
       if (!parentHdl.isReady()) {
-        // Parnet handle isn't ready. This can be due to the parent got evicted
+        // Parent handle isn't ready. This can be due to the parent got evicted
         // into NvmCache, or another thread is moving the slab that the parent
         // handle is on (e.g. the parent got replaced and the new parent's slab
         // is being moved). In this case, we must wait synchronously and block
         // the current slab moving thread until parent is ready. This is
         // expected to be very rare.
         parentHdl.wait();
       }
-      wakeUpWaiters(parentItem->getKey(), std::move(parentHdl));
+      wakeUpWaiters(parentKeyView, std::move(parentHdl));
     }
   } else {
     auto ref = unmarkMovingAndWakeUpWaiters(oldItem, std::move(newItemHdl));