SurrealDB before 3.3.0 Use-After-Free via affinitypool spawn_local in KV Backends

SurrealDB before 3.3.0 contains a use-after-free vulnerability in surrealdb-core KV backends that pass borrowed transaction state into affinitypool::spawn_local closures relying on future Drop for safety. Rust embedders that leak a dispatched future (e.g. via mem::forget) and drop the transaction cause pool workers to read and write freed memory, risking crashes or memory corruption.

SurrealDB before 3.3.0 contains a use-after-free vulnerability in surrealdb-core KV backends that pass borrowed transaction state into affinitypool::spawn_local closures relying on future Drop for safety. Rust embedders that leak a dispatched future (e.g. via mem::forget) and drop the transaction cause pool workers to read and write freed memory, risking crashes or memory corruption.

SurrealDB before 3.3.0 contains a use-after-free vulnerability in surrealdb-core KV backends that pass borrowed transaction state into affinitypool::spawn_local closures relying on future Drop for safety. Rust embedders that leak a dispatched future (e.g. via mem::forget) and drop the transaction cause pool workers to read and write freed memory, risking crashes or memory corruption.

The `kv-mem`, `kv-surrealkv` and `kv-rocksdb` backends move non-`'static` borrowed state into affinity-pool closures through `affinitypool::spawn_local`: a `tokio::sync::MutexGuard<Option<TransactionInner>>`, `&Transaction`, `&mut ScanStateKeys/Vals`, `&mut dyn KeyVisitor/ValVisitor`, `RwLockReadGuard`, and a `ReadOptions` holding a raw `rocksdb_snapshot_t*`. In `affinitypool 0.7.0` `spawn_local` is safe and erases the `'pool` lifetime via `async_task::Builder::spawn_unchecked`; the only thing keeping it sound is the `Drop` implementation of the returned future, which blocks until the worker stops using the borrows. Safe code can leak that future (`mem::forget`, `Box::leak`, `ManuallyDrop`, a reference cycle, or a leaked enclosing future). The borrows then end while the pool worker still uses them, producing a use-after-free on the transaction allocation; AddressSanitizer reports a read of freed mutex data and a write when the worker unlocks the freed `tokio::sync::Mutex` on the pool thread. No `unsafe` is required at the call site, and the affected methods include `count`, `keys`/`keysr`, `scan`/`scanr`, `compact`, shutdown, point reads and writes, and cursor iteration. 3.3.0 upgrades to `affinitypool 0.8.0`, where `spawn_local` is an `unsafe` function and the caller must uphold the leak-freedom invariant (commit `8156ff69`).