CVE-2026-44983

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

#![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);
}

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

• 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)

An arithmetic operation produces a value that exceeds the integer type's maximum, causing it to wrap to an unexpected small value. Typical impact: incorrect size calculations leading to heap overflows or logic errors.

CVE-2026-44983 has a CVSS score of 7.3 (High). The vector is requires local access, no privileges required, and no user interaction. A CVSS score reflects the worst-case severity of the vulnerability, not your specific exposure. Whether this affects your application depends on whether the vulnerable code is present and reachable in your environment. No fixed version is listed yet, so configuration controls and monitoring matter more in the interim.

Kodem intelligence

1. What is CVE-2026-44983? CVE-2026-44983 is a high-severity integer overflow or wraparound vulnerability in smallbitvec (rust), affecting versions >= 1.0.1, <= 2.6.0. No fixed version is listed yet. An arithmetic operation produces a value that exceeds the integer type's maximum, causing it to wrap to an unexpected small value.
2. How severe is CVE-2026-44983? CVE-2026-44983 has a CVSS score of 7.3 (High). This score reflects the worst-case severity of the vulnerability, not your specific exposure. Whether it represents real risk in your environment depends on whether the vulnerable code is present and reachable.
3. Which versions of smallbitvec are affected by CVE-2026-44983? smallbitvec (rust) versions >= 1.0.1, <= 2.6.0 is affected.
4. Is there a fix for CVE-2026-44983? No fixed version is listed for CVE-2026-44983 yet. Monitor the advisory for updates and apply mitigations in the interim.
5. Is CVE-2026-44983 exploitable, and should I be worried? Whether CVE-2026-44983 is exploitable in your environment depends on whether the vulnerable code is present and reachable. A CVSS score is a worst-case rating; it does not account for your specific deployment, configuration, or usage patterns. Kodem, an Intelligent Application Security platform, uses runtime intelligence to show which vulnerabilities actually execute in production, so you can focus on the ones that represent real risk. Get a demo
6. What actually determines whether CVE-2026-44983 is exploitable, and how bad it is? Exploitability and impact are not fixed properties of a CVE. They depend on runtime truth: whether the vulnerable code is present, reachable, and actually executes in your application. A high CVSS score on a dependency that never runs is not the same as real risk. Kodem, an Intelligent Application Security platform, uses runtime intelligence to reveal which vulnerabilities actually execute in production, so teams prioritize the ones that genuinely matter.
7. How do I fix CVE-2026-44983? No fixed version is listed yet. In the interim: Keep the dependency up to date. In native-code projects, use checked arithmetic or integer types that enforce bounds.