GHSA-Q95X-7G78-RCCV: Safe Rust Memory Corruption via Use-After-Free in oneringbuf Crate

The oneringbuf crate is a Rust-based collection of ring buffer implementations supporting stack-allocated, heap-allocated, and virtual-memory-backed storage. In versions prior to 0.8.0, the library exposed a public trait IntoRef with an associated method into_ref. This method permitted consumers to convert ring buffers into reference-like wrapper structures, such as DroppableRef for heap-backed storage, which was intended to simplify reference management.

The primary attack surface is the public API of the crate. By exposing IntoRef::into_ref, the API enabled downstream consumers to construct DroppableRef handles. The DroppableRef type wrapped raw pointers to heap-allocated buffers but did not properly track its active references. This configuration violates the Rust memory-safety model by exposing unsafe raw pointer operations through a fully safe public API.

Consequently, an unauthenticated local or remote attacker could trigger memory corruption, including Use-After-Free (UAF) or Double Free conditions, if they can control execution paths that utilize this API. The vulnerability belongs to the CWE-416 (Use After Free) class, leading to potential denial of service or arbitrary code execution depending on how the application processes or retrieves the affected buffers.

The root cause of the vulnerability lies in the interaction between the public IntoRef::into_ref trait method and the implementation of the Clone and Drop traits on the DroppableRef wrapper. When a heap-backed ring buffer such as LocalHeapRB or any buffer utilizing HeapStorage or VmemStorage is converted into a reference via into_ref, a DroppableRef wrapper is created. This wrapper encapsulates a raw pointer of type NonNull<B> pointing to the underlying heap buffer.

The DroppableRef struct implements the Clone trait. However, its cloning mechanism is flawed because it performs a trivial copy of the internal NonNull raw pointer. It does not increment any central reference counter or the crate's internal iterator state tracking (alive_iters). This results in multiple DroppableRef instances pointing to the exact same memory address, each unaware of the existence of the other clones.

The Drop implementation of DroppableRef is responsible for freeing the backing heap allocation when it is no longer needed. To do this, it invokes Box::from_raw on the internal raw pointer once its tracking indicates no more iterators are active. Because cloning the reference wrapper bypasses the reference tracking mechanisms, dropping the first cloned wrapper prematurely triggers deallocation. The other active wrappers are left pointing to deallocated memory, forming dangling pointers. Any subsequent drop or access operation on these dangling pointers results in a Use-After-Free or a Double Free.

The following diagram illustrates the relationship between the cloned wrappers and the backing heap allocation, leading to the Use-After-Free condition:

Prior to version 0.8.0, the IntoRef trait in src/ring_buffer/wrappers/refs/mod.rs was defined as follows:

pub trait IntoRef {
    type TargetRef: BufRef<Buffer = Self>;
 
    // Vulnerable: Public method allowing safe construction of reference wrappers
    fn into_ref(s: Self) -> Self::TargetRef;
}

This allowed user code to invoke into_ref safely. The trait was implemented for heap-backed storage in src/ring_buffer/impls.rs:

#[cfg(feature = "alloc")]
impl<T, I: IterComponent> IntoRef for OneRingBuf<HeapStorage<T>, I> {
    type TargetRef = DroppableRef<Self>;
 
    // Vulnerable: Safely wraps the structure into DroppableRef
    fn into_ref(s: Self) -> Self::TargetRef {
        DroppableRef::from(s)
    }
}

The patch introduced in commit 643a24b30914068416dff9021a069c12c865a316 resolved this by completely stripping the into_ref method from the public trait interface:

// Patched version of IntoRef in src/ring_buffer/wrappers/refs/mod.rs
pub trait IntoRef {
    type TargetRef: BufRef<Buffer = Self>;
    // The into_ref method is completely removed
}

Similarly, the implementations of IntoRef in src/ring_buffer/impls.rs were updated to remove the definitions of into_ref. Because the method no longer exists, downstream safe Rust code can no longer instantiate DroppableRef or NonDroppableRef objects directly, mitigating the risk of incorrect cloning and premature deallocation.

Exploiting this vulnerability does not require any specific unsafe block in downstream code. Because the vulnerable methods were marked as safe public functions, an application developer could inadvertently write standard Rust code that causes memory corruption. The prerequisite is that the target application must instantiate a heap-backed ring buffer, call the IntoRef::into_ref method, clone the resulting reference wrapper, and allow the original reference to go out of scope or explicitly drop it.

A functional proof-of-concept demonstrating the flaw is presented below. In this scenario, we initialize a LocalHeapRB buffer, obtain a wrapper r, clone it twice (r2 and r3), and then drop the instances in sequence:

use oneringbuf::{IntoRef, LocalHeapRB};
 
fn main() {
    // Initialize heap-backed ring buffer
    let rb = LocalHeapRB::<usize>::from(vec![1, 2, 3]);
 
    // Create initial DroppableRef wrapper via safe API
    let r = <LocalHeapRB<usize> as IntoRef>::into_ref(rb);
    
    // Clone the wrapper, copying the raw pointer without updating reference counters
    let r2 = r.clone();
    let r3 = r.clone();
 
    // Dropping the original wrapper reclaims the backing storage using Box::from_raw
    drop(r);
 
    // Dropping r2 accesses/manipulates the deallocated storage
    drop(r2);
 
    // Dropping r3 attempts to reclaim the already deallocated heap block (Double Free)
    drop(r3); 
}

When this program is compiled and executed under AddressSanitizer (ASan), it immediately halts execution with a heap Use-After-Free diagnostic during the destruction of r2 or r3. If compiled under standard release configurations without sanitizers, the execution state becomes unpredictable, leading to heap corruption that could be manipulated for control flow hijack or denial of service depending on the allocator configuration.

The impact of this vulnerability is critical for any application relying on the memory safety guarantees of the Rust programming language. Because the vulnerability allows safe Rust code to trigger raw pointer deallocation, it bypasses the compiler's compile-time borrow checker checks. Consequently, applications that expose endpoints consuming or manipulating user-controlled input within these ring buffers may be vulnerable to remote exploits.

If an attacker can control the contents or timing of the deallocated heap space (heap spraying), they may be able to replace the deallocated OneRingBuf structure with malicious payloads. This could lead to arbitrary code execution within the context of the running application process. If code execution is not achieved, the vulnerability reliably causes application crashes, creating a vector for localized or remote Denial of Service (DoS).

The CVSS v4.0 base score is evaluated at 6.3 (Medium). This indicates that while the vulnerability represents a significant memory safety violation, exploitation is restricted by the requirement that the target program must actively employ the into_ref method of the oneringbuf crate. No active exploitation has been detected in the wild.

The recommended remediation is to upgrade the oneringbuf crate dependency to version 0.8.0 or higher. This version completely eliminates the into_ref method from the public trait, which prevents the instantiation of the unsafe wrappers by external code.

We assess this fix as complete for downstream safe Rust consumers. By removing the public API entrypoint, the maintainer has enforced compile-time safety. Downstream code will fail to compile if it attempts to call into_ref. There are no alternative safe paths in the crate that expose DroppableRef or NonDroppableRef to external callers.

For deployments where immediate upgrading is not viable, developers should audit their codebases to ensure that IntoRef::into_ref is never called. If the trait method is used, it should be refactored to utilize native Rust borrowing mechanisms (such as standard references & or &mut, or standard smart pointers like Rc or Arc) instead of the crate's custom reference wrappers.