Skip to main content

smallbitvec CVE-2026-44983

HIGH
Heap-based Buffer Overflow (CWE-122)
2026-05-09 https://github.com/servo/smallbitvec GHSA-97wc-2hqc-cjgr
7.3
CVSS 3.1 · GitHub Advisory
Share

Severity by source

GitHub Advisory PRIMARY
7.3 HIGH
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
Attack Vector
Local
Attack Complexity
Low
Privileges Required
None
User Interaction
None
Scope
Unchanged
Confidentiality
Low
Integrity
Low
Availability
High

Lifecycle Timeline

3
Source Code Evidence Fetched
May 09, 2026 - 01:15 vuln.today
Analysis Generated
May 09, 2026 - 01:15 vuln.today
CVE Published
May 09, 2026 - 00:02 nvd
HIGH 7.3

DescriptionGitHub 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() - 1

can 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
rust
#![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
rust
#![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.

Share

CVE-2026-44983 vulnerability details – vuln.today

This site uses cookies essential for authentication and security. No tracking or analytics cookies are used. Privacy Policy