smallbitvec CVE-2026-44983
HIGHSeverity by source
AV:L/AC:L/PR:N/UI:N/S:U/C:L/I:L/A:H
Primary rating from GitHub Advisory · only source for this CVE.
CVSS VectorGitHub Advisory
CVSS:3.1/AV:L/AC:L/PR:N/UI:N/S:U/C:L/I:L/A:H
Lifecycle Timeline
3DescriptionGitHub Advisory
Summary
An integer overflow in the internal capacity calculation of smallbitvec can lead to an undersized heap allocation, resulting in a heap buffer overflow through safe APIs only. This allows memory corruption without requiring unsafe code from the caller.
Details
The issue originates from unchecked arithmetic in the internal helper function responsible for computing the required buffer size:
(cap + bits_per_storage() - 1) / bits_per_storage()When cap is close to usize::MAX, the addition:
cap + bits_per_storage() - 1can overflow in release builds and wrap around due to Rust’s default wrapping semantics for integer overflow in optimized builds.
As a result:
buffer_len(cap)may return a value significantly smaller than required.- The backing storage is allocated with insufficient size.
- Internal metadata (logical length/capacity) reflects a much larger size than the actual allocation.
Subsequent safe API calls (e.g., set, push, reserve) rely on this corrupted metadata and perform index computations that assume sufficient backing storage. These operations eventually reach unsafe internal code paths (e.g., pointer arithmetic and unchecked indexing), leading to out-of-bounds memory access.
Summary of the issue: integer overflow → undersized allocation → inconsistent metadata (len/cap vs actual buffer) → unsafe internal access using corrupted metadata → heap buffer overflow (UB)
PoC
PoC 1: Out-of-bounds write via from_elem
#![forbid(unsafe_code)]
use smallbitvec::SmallBitVec;
fn main() {
// Triggers overflow in buffer_len(cap)
let mut v = SmallBitVec::from_elem(usize::MAX, false);
// Logical length is large, but backing storage is undersized
// This leads to out-of-bounds write in unsafe internals
v.set(0, true);
}PoC 2: Overflow via reserve
#![forbid(unsafe_code)]
use smallbitvec::SmallBitVec;
fn main() {
let mut v = SmallBitVec::new();
v.push(true);
// Triggers overflow in capacity computation
v.reserve(usize::MAX - 10);
}Impact
- Heap buffer overflow via safe API only
- ASAN-observable heap-buffer-overflow
- Undefined Behavior detectable with Miri (e.g., out-of-bounds indexing due to corrupted metadata)
Tested on
- rustc 1.96.0-nightly (9602bda1d 2026-04-05)
- Target: x86_64-unknown-linux-gnu
- Build: release
- ASAN:
RUSTFLAGS="-Z sanitizer=address" cargo +nightly run --release - Miri:
cargo +nightly miri run --release
AnalysisAI
Integer overflow in Rust crate smallbitvec allows heap buffer overflow through safe API calls when capacity values approach usize::MAX. The vulnerability affects versions 1.0.1 through 2.6.0 and enables memory corruption without requiring unsafe code blocks, violating Rust's memory safety guarantees. Publicly available exploit code exists with working proof-of-concept demonstrating ASAN-detectable heap corruption. CVSS 7.3 reflects local attack vector, but the vulnerability is notable because it breaks Rust's core safety model by achieving undefined behavior through safe APIs alone.
Technical ContextAI
The smallbitvec crate provides a compact bit vector implementation for Rust. The vulnerability resides in an internal capacity calculation helper that uses unchecked arithmetic: (cap + bits_per_storage() - 1) / bits_per_storage(). In Rust release builds, integer overflow follows wrapping semantics by default rather than panicking. When capacity values near usize::MAX are provided, the addition wraps around to a small value, causing buffer_len() to return an undersized allocation requirement. The crate then allocates insufficient heap memory while maintaining metadata (logical length/capacity) that reflects the original large size. Subsequent safe API operations like set(), push(), and reserve() rely on this corrupted metadata for bounds checking, but the actual unsafe pointer arithmetic and indexing in the implementation accesses memory beyond the allocated buffer. This represents a CWE-122 heap-based buffer overflow triggered through an integer overflow (CWE-190) in safe code, which is particularly severe in Rust's memory-safe ecosystem where such violations are expected to require explicit unsafe blocks.
RemediationAI
No vendor-released patch identified at time of analysis - the GitHub advisory (GHSA-97wc-2hqc-cjgr) lists vulnerable versions 1.0.1-2.6.0 with no fixed version specified, indicating the maintainers have not yet released a patched version. Organizations using smallbitvec should implement immediate compensating controls: (1) Add input validation to reject capacity values exceeding a reasonable maximum (e.g., cap > isize::MAX or cap > 1GB worth of bits) before passing to SmallBitVec::from_elem(), reserve(), or with_capacity() - this prevents the overflow trigger but may break legitimate use cases requiring very large bit vectors. (2) Review all call sites where external input influences SmallBitVec capacity parameters and implement strict bounds checking. (3) Consider migrating to alternative crates such as bitvec or bit-vec that have active maintenance and no known similar vulnerabilities, though migration requires code changes and testing. (4) Enable overflow checks in release builds via RUSTFLAGS="-C overflow-checks=on" during compilation - this converts wrapping overflow to panic, preventing memory corruption but causing denial-of-service when overflow occurs (acceptable trade-off for memory safety). Monitor the GitHub advisory and crates.io for patched releases. Until a fix is available, the most practical mitigation for most applications is input validation limiting capacity to safe maximums with explicit error handling.
Same weakness CWE-122 – Heap-based Buffer Overflow
View allSame technique Heap Overflow
View allShare
External POC / Exploit Code
Leaving vuln.today
GHSA-97wc-2hqc-cjgr