RUSTSEC-2026-0453 (GHSA-PM86-CC75-Q463)
Vulnerability from osv_rustsec – Published: 2026-10-19 12:00 – Updated: 2026-11-06 15:34 – Source websiteThe 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).
{
"affected": [
{
"database_specific": {
"categories": [
"memory-corruption"
],
"cvss": "CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:C/C:H/I:H/A:H",
"informational": null
},
"ecosystem_specific": {
"affected_functions": null,
"affects": {
"arch": [],
"functions": [],
"os": []
}
},
"package": {
"ecosystem": "crates.io",
"name": "surrealdb",
"purl": "pkg:cargo/surrealdb"
},
"ranges": [
{
"events": [
{
"introduced": "0.0.0-0"
},
{
"fixed": "3.3.0"
}
],
"type": "SEMVER"
}
],
"versions": []
}
],
"aliases": [
"GHSA-pm86-cc75-q463"
],
"database_specific": {
"license": "CC0-1.0"
},
"details": "The `kv-mem`, `kv-surrealkv` and `kv-rocksdb` backends move non-`\u0027static` borrowed state into affinity-pool closures through `affinitypool::spawn_local`: a `tokio::sync::MutexGuard\u003cOption\u003cTransactionInner\u003e\u003e`, `\u0026Transaction`, `\u0026mut ScanStateKeys/Vals`, `\u0026mut 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 `\u0027pool` 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.\n\nSafe 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.\n\n3.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`).",
"id": "RUSTSEC-2026-0453",
"modified": "2026-11-06T15:34:32Z",
"published": "2026-10-19T12:00:00Z",
"references": [
{
"type": "PACKAGE",
"url": "https://crates.io/crates/surrealdb"
},
{
"type": "ADVISORY",
"url": "https://rustsec.org/advisories/RUSTSEC-2026-0453.html"
},
{
"type": "WEB",
"url": "https://github.com/surrealdb/surrealdb/commit/8156ff691b1861814199e5e3372c81609b68db7f"
}
],
"related": [],
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:C/C:H/I:H/A:H",
"type": "CVSS_V3"
}
],
"summary": "Use-after-free in KV backends via leaked `affinitypool::spawn_local` future"
}
Drag nodes to arrange them. Double-click a related vulnerability to open it, or a source to visit its link. The Physics button on the left tunes the layout and the simulation; the legend at the bottom left hides or shows nodes by kind and by sighting type.
Sightings
| Author | Source | Type | Date | Other |
|---|
Nomenclature
- Seen: The vulnerability was mentioned, discussed, or observed by the user.
- Confirmed: The vulnerability has been validated from an analyst's perspective.
- Published Proof of Concept: A public proof of concept is available for this vulnerability.
- Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
- Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
- Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
- Not confirmed: The user expressed doubt about the validity of the vulnerability.
- Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.
Vulnerability timeline
Sightings and recorded dates, grouped by day · UTC
Loading timeline…
The approach is described in our paper Mapping CVEs to MITRE ATT&CK Techniques: A Curated Gold-Set Classifier and the Limits of LLM-Assisted Label Expansion.
Browse all ATT&CK techniques and the vulnerabilities related to each.
Related by attack behaviour
Vulnerabilities whose description is nearest to this one in the vector space of the CIRCL/vulnerability-attack-technique-biencoder model. This is a similarity search over the bi-encoder space (plain cosine), not a classification, and it has no measured accuracy.