PT-2026-42962 · Crates.Io · Mutringbuf

Publicado

2026-05-14

·

Atualizado

2026-05-14

Nenhuma

Não há classificações de severidade ou métricas disponíveis. Quando houver, atualizaremos as informações correspondentes na página.
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 -> abort

Fix

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.
Encontrou algum problema na descrição? Tem algo a acrescentar? Fique à vontade para nos escrever 👾

Identificadores relacionados

RUSTSEC-2026-0142

Produtos afetados

Mutringbuf