RUSTSEC-2025-0105: Uninitialized memory exposure in create_ring_buffer

What to do

1. See which version you have: cargo tree -i direct_ring_buffer (it also shows which of your dependencies pulls it in).
2. Update within your version requirement: cargo update -p direct_ring_buffer. If the fix is a newer major or minor than your requirement allows, raise it in Cargo.toml (for example direct_ring_buffer = "0.2.2") or update the dependency that pulls it in.
3. Check again with cargo audit, or paste your Cargo.lock into our Cargo.toml checker.

Details from the advisory

The safe function create_ring_buffer allocates a buffer using Vec::with_capacity followed by set_len, creating a Box<[T]> containing uninitialized memory.

This leads to undefined behavior when functions like write_slices create typed slices (e.g., &mut [bool]) over the uninitialized memory, violating Rust's validity invariants. The issue has been confirmed using Miri.

Fixed in version 0.2.2 by using resize_with to properly initialize the buffer with T::default(), adding a T: Default bound to ensure sound initialization.

References

• Package: crates.io/crates/direct_ring_buffer
• Advisory: rustsec.org/advisories/RUSTSEC-2025-0105.html
• Report: github.com/ain1084/direct_ring_buffer/issues/1
• Web: github.com/ain1084/direct_ring_buffer/pull/2

From the RustSec Advisory Database (CC0-1.0) via the OSV export, downloaded Oct 24, 2026. Severity score computed from the published CVSS vector.