Rust Crate StackVec Exposes Length Field That Lets Safe Code Trigger UB

StackVec's public length field let any safe Rust code set it to a value larger than the backing array's capacity. That's not a bug—that's a footgun with the safety label peeled off.

Version 2.0.0 of the stackvector crate now patches the whole mess, but every dependency pulling in <2.0.0 was silently exposing your program to out-of-bounds pointer arithmetic, reads, writes, and copies.

Public Field That Shouldn’t Have Been Public

The StackVec::length field wasn't protected by an invariant check. Safe code could increment it past the allocated buffer size. Once corrupted, every method that relied on length before touching raw pointers became a landmine:

• remove used ptr::copy with the corrupted index
• pop read from an out-of-bounds offset via ptr::read
• truncate compared against the bogus length and then called ptr::drop_in_place on garbage

All of these are undefined behavior in Rust's memory model. No unsafe block required to trigger it—just assign stackvec.length = u32::MAX and watch your safety guarantees evaporate.

Beyond the Public Field

The upstream maintainer (Alexhuszagh) identified additional soundness issues in the same codebase:

• StackVec::from_vec_unchecked called mem::uninitialized, which is deprecated and known to create uninitialized memory that violates Rust's validity invariants. This function was reachable through the safe from_vec API.
• Miri (the Rust undefined behavior checker) flagged violations related to MaybeUninit usage.

A single version bump—2.0.0—closes all known soundness holes. The advisory was registered with RUSTSEC on 2025-10-23 and the commit fixing the issues is 02b947afdeeb1be95ec0888354aa76afdd9d0357.

What This Means for Your Dependency Tree

If you use stackvector directly or transitively, run cargo audit and check for versions below 2.0.0. The fix is a minor semver bump but the security implications are not minor—this is unsoundness that safe code can trigger without any unsafe keyword. Every CI pipeline that doesn't scan for RUSTSEC advisories is flying blind here.

The advisory is a specific reminder that public fields in Rust's standard library-style containers should never be mutable without bounds checking, and that raw-pointer-based data structures need thorough Miri testing even when the public API looks safe.

Source: Add advisory for stackvector public length field unsoundness (#3005)
Domain: github.com