Skip to content
Fencer Vulns
high 7.9

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

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.