GHSA-9fm9-c4h4-8g93 json
Out-of-bounds read when decoding internal keys shorter than 16 bytes
published 2026-11-03 5 d ago modified 2026-11-06 2 d ago also RUSTSEC-2026-0452
- cvss
- 7.9
- version 3.1, OSV
- cisa kev
- Not listed
- not in CISA's catalog
- epss
- —
- no score, EPSS covers CVEs only
- public exploits
- 0
- none known
Summary
`InternalKeyRef::from_encoded` is a safe constructor whose only length check is `debug_assert!(encoded.len() >= 16)`, which is compiled out in release builds. Its accessors perform unchecked length arithmetic on the slice: `user_key()` slices `&encoded[..len - 16]`, `trailer()`/`seq_num()` pass `len - 16` and `timestamp()` passes `len - 8` to `read_u64_be`, which computes `buffer.as_ptr().add(offset)` and performs an 8-byte load. For a short slice the subtraction underflows `usize`, the pointer wraps below the allocation and eight bytes before the buffer are read (undefined behavior; confirmed with AddressSanitizer as a `heap-buffer-overflow`). In debug builds the same call panics instead.
The same invariant is missing at the on-disk decode boundary: `BlockIterator::seek_next_entry` rebuilds the current key from block bytes with upper-bound checks only, and `BlockIterator::key()` wraps it in `InternalKeyRef`, which `surrealdb`'s `kv-surrealkv` backend then reads through `key_ref.timestamp()`. A crafted or corrupted SSTable therefore reaches the same unchecked subtraction without any `unsafe` at the call site.
`1.2.0` rejects internal keys shorter than their 8-byte trailer before any accessor computes an offset and makes the accessors bounds-checked (fix in commit `ac642f9`, `surrealdb` 4.0.0 ships `surrealkv` 1.2.0).
Patch / fix
- crates.io surrealkv 1.2.0
- github.com/surrealdb/surrealkv@ac642f9 commit
- github.com/surrealdb/surrealkv#497 pull request
CVSS scores
| assigned by | version | score | vector |
|---|---|---|---|
| OSV | 3.1 | 7.9 | CVSS:3.1/AV:L/AC:L/PR:N/UI:N/S:C/C:H/I:N/A:L |
Affected packages
| ecosystem | package | affected | fixed in |
|---|---|---|---|
| crates.io | surrealkv | >=0.0.0-0, <1.2.0 |
1.2.0 |
References
Sources
Fencer Vulns keeps one entry per vulnerability: the CVE id wins, then GHSA, and records that alias each other are merged, except that two CVEs always keep separate entries. The same data is available as JSON.