RustSec flags oneringbuf unsoundness, safe API hides double-free risk

The uncomfortable lesson in RustSec’s latest `oneringbuf` advisory is simple: a safe API is only as trustworthy as the unsafe machinery underneath it. RustSec tagged RUSTSEC-2026-0143 as an INFO-level memory-corruption issue on May 14, and the warning centers on `oneringbuf::VmemStorage::new` in versions below 0.7.1. The advisory’s keywords tell the story plainly enough, with double-free, use-after-free, vmem, and drop all in the same report, and RustSec says the bug was reachable from 100% safe Rust.

The failure sits in the crate’s `vmem` feature. `VmemStorage<T>::new` and the constructors that feed into it bit-copy a source buffer into a freshly mmap’d region, then let the original `Box<[UnsafeSyncCell<T>]>` fall out of scope normally. That would already be dangerous, but the problem becomes deterministic because `UnsafeSyncCell<T>` has a `Drop` implementation that calls `assume_init_drop` on its inner value. In practice, the source-side values are dropped as `new` finishes, while bitwise duplicates with the same heap pointers remain in the mmap region. When the ring buffer later tears down, those same elements are dropped again.

The reproducer uses `Vec<Vec<u32>>`, which makes the bug impossible to brush off as a corner case involving exotic types. On glibc, the program aborts with `free(): double free detected in tcache 2`; AddressSanitizer reports an attempted double-free. That is the kind of failure that tells maintainers exactly where the ownership model went wrong: the bytes moved, but the destructor semantics did not. RustSec lists the patched range as 0.7.1 and up, says the upstream fix landed in Skilvingr/rust-oneringbuf#3, and notes that the vulnerable releases were yanked from crates.io.

The parallel `mutringbuf` advisory adds an important bit of history. RustSec says `mutringbuf` was the archived predecessor of `oneringbuf`, that the GitHub repository was archived on 2025-11-20, and that all released versions up to 1.0.0 carried the same `vmem` double-free bug. The crate’s README describes `oneringbuf` as an SPSC ring buffer aimed at real-time uses such as audio stream processing, which makes the flaw harder to ignore. A crate can promise a safe surface and still hide a memory-safety trap if the unsafe layer gets ownership even slightly wrong, and this one did exactly that.