GHSA-VFVV-C25P-M7MM: Memory Corruption via Panic Safety Flaw in rkyv Collections

The rkyv library is a zero-copy deserialization framework for Rust. It provides custom vector implementations, specifically InlineVec and SerVec, to manage memory during serialization and deserialization processes. These collections handle memory allocations and deallocations manually to optimize performance.

A vulnerability tracked as GHSA-VFVV-C25P-M7MM and RUSTSEC-2026-0122 exists in the memory management logic of these custom collections. The issue stems from a lack of panic safety during the execution of element destructors. The vulnerability affects rkyv versions strictly greater than or equal to 0.8.0 and less than 0.8.16.

When an element's Drop implementation panics during a call to the clear method, the container's internal length field remains unaltered. This discrepancy between the logical state and the physical memory state leads to undefined behavior. The vulnerability exposes applications to memory corruption risks, primarily Use-After-Free and Double Free conditions.

The root cause lies in the sequencing of operations within the InlineVec::clear and SerVec::clear functions. These functions are responsible for deallocating the objects held within the collections by iterating over them and invoking drop_in_place. This function runs the destructors for the allocated memory regions.

In the vulnerable design, the collections wait for the iteration loop to complete successfully before resetting their internal len fields to zero. This approach assumes that destructors will never panic, which violates strict Rust panic safety guarantees. The length update is executed as the final step of the function block.

If a panic occurs while processing an element, normal control flow is interrupted by unwinding. The loop terminates prematurely, and the function's final length assignment is bypassed entirely. The container exits the function execution prematurely but maintains its previous state.

Because the length field is not decremented, the collection struct retains logical ownership over the entire original array of objects. Elements that were successfully destroyed prior to the panic are still considered active members of the vector, leading to dangling pointers within the container's accessible range.

The flawed logic is visible in the vulnerable implementation of the clear method. The function iterates through the allocated elements and drops them sequentially. The critical length update is positioned at the very end of the function body, leaving a window for panic unwinding to bypass the state update.

// VULNERABLE CODE (Simplified)
pub fn clear(&mut self) {
    for i in 0..self.len {
        unsafe {
            self.elements[i].as_mut_ptr().drop_in_place();
        }
    }
    // State is updated AFTER the potentially panicking loop
    self.len = 0; 
}

The fix implemented in commit 5828cf5c27b664eb4432c4a93d4769e12e5e42fb adopts the "Commit Before Side-Effect" design pattern. The length field is stored locally and immediately zeroed out before any destructors are invoked. This ensures the container reflects an empty state prior to executing arbitrary Drop code.

// PATCHED CODE (Simplified)
pub fn clear(&mut self) {
    let len = self.len;
    // State is committed BEFORE the side-effect operations
    self.len = 0; 
 
    for i in 0..len {
        unsafe {
            self.elements[i].as_mut_ptr().drop_in_place();
        }
    }
}

By separating the state update from the side-effecting operations, the function ensures the collection remains consistent even during unwinding. Any subsequent attempts to access or drop the vector will perceive it as empty, completely mitigating the double-free condition.

Exploitation requires a specific program state where an attacker controls the data types being managed by rkyv or can intentionally trigger a panic within a custom Drop implementation. The vulnerability triggers undefined behavior via two primary mechanisms during the unwinding phase. Both mechanisms require the application to process complex types with panicking destructors.

The first mechanism is a Double Free condition (CWE-415). If the unwinding process subsequently drops the InlineVec or SerVec container itself, the container's destructor will re-iterate over the full length of the vector. The unmodified length field directs the program to drop the entire collection array again.

During this second iteration, the system re-invokes destructors on the memory regions that were already freed before the initial panic occurred. This double invocation results in heap corruption that can crash the application or facilitate arbitrary code execution depending on the underlying allocator.

The second mechanism is a Use-After-Free condition (CWE-416). This occurs if the application catches the panic using the std::panic::catch_unwind facility and resumes standard execution. The program regains access to the original vector, whose length field falsely advertises the presence of valid elements. Accessing elements at the lower indices references the deallocated memory.

The maintainers resolved the vulnerability in rkyv version 0.8.16. Organizations utilizing this crate must upgrade their dependencies to incorporate the panic-safe memory management logic. Updating the package strictly removes the flaw without requiring architectural changes to consumer applications.

Software engineers developing custom memory allocators or containers in Rust must adhere strictly to panic safety principles. State changes that govern memory ownership must be finalized before invoking user-controlled code. This "Commit Before Side-Effect" pattern is mandatory for safe unsafe-code encapsulation.

Developers should review custom implementations of functions like clear, truncate, and pop. The internal length and capacity fields must accurately reflect the memory state prior to executing drop_in_place. Manual drops inside a loop require extreme caution regarding how unwinding behaves at each step.

To detect similar flaws, security teams can leverage dynamic analysis tools such as Miri. Executing test suites with Miri enabled and intentionally introducing panicking destructors will rapidly expose inconsistent memory states and dangling pointers.