Slice Ring Buffer and Slice Deque contains four unique double-free vulnerabilities triggered through safe APIs

[cbs228]

@dependabot writes concerning: RUSTSEC-2025-0044

The crate slice-ring-buffer was developed as a fork of slice-deque to continue maintenance and provide security patches, since the latter has been officially unmaintained (RUSTSEC-2020-0158).

While slice-ring-buffer has addressed some previously reported memory safety issues inherited from its fork origin (RUSTSEC-2021-0047), it still retains multiple unresolved memory corruption vulnerabilities.

Specifically, we have discovered four new memory safety bugs, each resulting in double-free violations that can occur when only safe APIs are invoked. These vulnerabilities correspond to four distinct safe APIs in the crate, each exposing unsound and vulnerable behavior due to incorrect usage of unsafe code internally.

Unfortunately, the maintainer doesn't have much availability to resolve these issues so there's no concrete timeline for fixes. Community contributions towards fixing these vulnerabilities would be much appreciated.

We have checked samedec's unit and integration tests against the Address Sanitizer:

RUSTFLAGS="-Zsanitizer=address" cargo +nightly-2025-06-01 test --target x86_64-unknown-linux-gnu
RUSTFLAGS="-Zsanitizer=address" cargo +nightly-2025-06-01 run --target x86_64-unknown-linux-gnu
sample/test.sh "$(realpath target/x86_64-unknown-linux-gnu/debug/samedec)"

This has not uncovered any memory safety defects in samedec.

The defects described in RUSTSEC-2025-0044 apply mainly to types which are !Copy because they own memory or other resources. Our crates only use slice-ring-buffer for storing simple, primitive types which are Copy. We do not anticipate any adverse effects from this advisory, but this issue will remain open until it is fixed.

See upstream issue LiquidityC/slice_ring_buffer#12.