PT-2026-42962 · Crates.Io · Mutringbuf
Published
2026-05-14
·
Updated
2026-05-14
None
No severity ratings or metrics are available. When they are, we'll update the corresponding info on the page.
mutringbuf is the archived predecessor of oneringbuf — the crate was renamed and the GitHub repository was archived on 2025-11-20. All released versions up to 1.0.0 carry the same vmem-feature double-free bug that affects oneringbuf, with the same code paths and the same reproduction shape.When the
vmem feature is enabled, VmemStorage<T>::new(Box<[UnsafeSyncCell<T>]>) (and every public constructor that funnels through it) bit-copies the input buffer into a freshly mmap'd region with ptr::copy nonoverlapping, then lets the source Box<[UnsafeSyncCell<T>]> drop normally. Because UnsafeSyncCell<T> has a Drop impl that runs assume init drop on its inner MaybeUninit<T>, the source-side T values are dropped at the end of new, while bitwise duplicates remain inside the mmap region. The ring-buffer destructor then runs UnsafeSyncCell::drop a second time on every cell — a deterministic double-free of every heap-owning element. Reachable from 100% safe Rust.Trigger
rust
let v: Vec<Vec<u32>> = (0..1024).map(|i| vec![i, i+1, i+2]).collect();
let rb: mutringbuf::SharedVmemRB<Vec<u32>> = mutringbuf::SharedVmemRB::from(v);
drop(rb);
// glibc: free(): double free detected in tcache 2 -> abortFix
mutringbuf is no longer maintained. The author renamed the crate to oneringbuf and shipped the fix as oneringbuf 0.7.1 (upstream PR skilvingr/rust-oneringbuf#3). All mutringbuf versions have been yanked from crates.io. Users should migrate to oneringbuf >= 0.7.1.See the parallel advisory for the
oneringbuf crate for the full technical write-up of the bug. Found an issue in the description? Have something to add? Feel free to write us 👾
Related Identifiers
Affected Products
Mutringbuf