smallbitvec

Version	Released
`2.6.1` unknown	May 06, 2026
`2.6.0` unknown 1 CVE	Feb 15, 2025
`2.5.3` unknown 1 CVE	Mar 17, 2024
`2.5.2` unknown 1 CVE	Mar 13, 2024
`2.5.1` unknown 1 CVE	Aug 05, 2021
`2.5.0` unknown 1 CVE	May 08, 2020
`2.4.0` unknown 1 CVE	May 15, 2019
`2.3.0` unknown 1 CVE	Dec 06, 2018
`2.2.0` unknown 1 CVE	Oct 26, 2018
`2.1.1` unknown 1 CVE	Jun 04, 2018
`2.1.0` unknown 1 CVE	Apr 17, 2018
`2.0.0` unknown 1 CVE	Apr 12, 2018
`1.1.0` unknown 1 CVE	Mar 28, 2018
`1.0.7` unknown 1 CVE	Sep 27, 2017
`1.0.6` unknown 1 CVE	Sep 15, 2017
`1.0.5` unknown 1 CVE	Sep 14, 2017
`1.0.4` unknown 1 CVE	Sep 11, 2017
`1.0.3` unknown 1 CVE	Sep 11, 2017
`1.0.2` unknown 1 CVE	Sep 10, 2017
`1.0.1` unknown 1 CVE	Sep 10, 2017
`1.0.0` unknown	Sep 09, 2017

2.6.1 unknown

May 06, 2026

2.6.0 unknown

1 CVE

CVE-2026-44983 GHSA-97wc-2hqc-cjgr May 09, 2026

smallbitvec: Integer overflow in safe API leads to heap buffer overflow

7.3 / 10

High

Local Low None None Unchanged Low Low High

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`

#![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

References

Updated Jun 08, 2026 · Source: OSV.dev

Feb 15, 2025

2.5.3 unknown

1 CVE

CVE-2026-44983 GHSA-97wc-2hqc-cjgr May 09, 2026

smallbitvec: Integer overflow in safe API leads to heap buffer overflow

7.3 / 10

High

Local Low None None Unchanged Low Low High

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`

#![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

References

Updated Jun 08, 2026 · Source: OSV.dev

Mar 17, 2024

2.5.2 unknown

1 CVE

CVE-2026-44983 GHSA-97wc-2hqc-cjgr May 09, 2026

smallbitvec: Integer overflow in safe API leads to heap buffer overflow

7.3 / 10

High

Local Low None None Unchanged Low Low High

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`

#![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

References

Updated Jun 08, 2026 · Source: OSV.dev

Mar 13, 2024

2.5.1 unknown

1 CVE

CVE-2026-44983 GHSA-97wc-2hqc-cjgr May 09, 2026

smallbitvec: Integer overflow in safe API leads to heap buffer overflow

7.3 / 10

High

Local Low None None Unchanged Low Low High

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`

#![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

References

Updated Jun 08, 2026 · Source: OSV.dev

Aug 05, 2021

2.5.0 unknown

1 CVE

CVE-2026-44983 GHSA-97wc-2hqc-cjgr May 09, 2026

smallbitvec: Integer overflow in safe API leads to heap buffer overflow

7.3 / 10

High

Local Low None None Unchanged Low Low High

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`

#![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

References

Updated Jun 08, 2026 · Source: OSV.dev

May 08, 2020

2.4.0 unknown

1 CVE

CVE-2026-44983 GHSA-97wc-2hqc-cjgr May 09, 2026

smallbitvec: Integer overflow in safe API leads to heap buffer overflow

7.3 / 10

High

Local Low None None Unchanged Low Low High

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`

#![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

References

Updated Jun 08, 2026 · Source: OSV.dev

May 15, 2019

2.3.0 unknown

1 CVE

CVE-2026-44983 GHSA-97wc-2hqc-cjgr May 09, 2026

smallbitvec: Integer overflow in safe API leads to heap buffer overflow

7.3 / 10

High

Local Low None None Unchanged Low Low High

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`

#![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

References

Updated Jun 08, 2026 · Source: OSV.dev

Dec 06, 2018

2.2.0 unknown

1 CVE

CVE-2026-44983 GHSA-97wc-2hqc-cjgr May 09, 2026

smallbitvec: Integer overflow in safe API leads to heap buffer overflow

7.3 / 10

High

Local Low None None Unchanged Low Low High

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`

#![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

References

Updated Jun 08, 2026 · Source: OSV.dev

Oct 26, 2018

2.1.1 unknown

1 CVE

CVE-2026-44983 GHSA-97wc-2hqc-cjgr May 09, 2026

smallbitvec: Integer overflow in safe API leads to heap buffer overflow

7.3 / 10

High

Local Low None None Unchanged Low Low High

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`

#![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

References

Updated Jun 08, 2026 · Source: OSV.dev

Jun 04, 2018

2.1.0 unknown

1 CVE

CVE-2026-44983 GHSA-97wc-2hqc-cjgr May 09, 2026

smallbitvec: Integer overflow in safe API leads to heap buffer overflow

7.3 / 10

High

Local Low None None Unchanged Low Low High

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`

#![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

References

Updated Jun 08, 2026 · Source: OSV.dev

Apr 17, 2018

2.0.0 unknown

1 CVE

CVE-2026-44983 GHSA-97wc-2hqc-cjgr May 09, 2026

smallbitvec: Integer overflow in safe API leads to heap buffer overflow

7.3 / 10

High

Local Low None None Unchanged Low Low High

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`

#![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

References

Updated Jun 08, 2026 · Source: OSV.dev

Apr 12, 2018

1.1.0 unknown

1 CVE

CVE-2026-44983 GHSA-97wc-2hqc-cjgr May 09, 2026

smallbitvec: Integer overflow in safe API leads to heap buffer overflow

7.3 / 10

High

Local Low None None Unchanged Low Low High

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`

#![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

References

Updated Jun 08, 2026 · Source: OSV.dev

Mar 28, 2018

1.0.7 unknown

1 CVE

CVE-2026-44983 GHSA-97wc-2hqc-cjgr May 09, 2026

smallbitvec: Integer overflow in safe API leads to heap buffer overflow

7.3 / 10

High

Local Low None None Unchanged Low Low High

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`

#![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

References

Updated Jun 08, 2026 · Source: OSV.dev

Sep 27, 2017

1.0.6 unknown

1 CVE

CVE-2026-44983 GHSA-97wc-2hqc-cjgr May 09, 2026

smallbitvec: Integer overflow in safe API leads to heap buffer overflow

7.3 / 10

High

Local Low None None Unchanged Low Low High

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`

#![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

References

Updated Jun 08, 2026 · Source: OSV.dev

Sep 15, 2017

1.0.5 unknown

1 CVE

CVE-2026-44983 GHSA-97wc-2hqc-cjgr May 09, 2026

smallbitvec: Integer overflow in safe API leads to heap buffer overflow

7.3 / 10

High

Local Low None None Unchanged Low Low High

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`

#![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

References

Updated Jun 08, 2026 · Source: OSV.dev

Sep 14, 2017

1.0.4 unknown

1 CVE

CVE-2026-44983 GHSA-97wc-2hqc-cjgr May 09, 2026

smallbitvec: Integer overflow in safe API leads to heap buffer overflow

7.3 / 10

High

Local Low None None Unchanged Low Low High

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`

#![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

References

Updated Jun 08, 2026 · Source: OSV.dev

Sep 11, 2017

1.0.3 unknown

1 CVE

CVE-2026-44983 GHSA-97wc-2hqc-cjgr May 09, 2026

smallbitvec: Integer overflow in safe API leads to heap buffer overflow

7.3 / 10

High

Local Low None None Unchanged Low Low High

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`

#![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

References

Updated Jun 08, 2026 · Source: OSV.dev

Sep 11, 2017

1.0.2 unknown

1 CVE

CVE-2026-44983 GHSA-97wc-2hqc-cjgr May 09, 2026

smallbitvec: Integer overflow in safe API leads to heap buffer overflow

7.3 / 10

High

Local Low None None Unchanged Low Low High

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`

#![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

References

Updated Jun 08, 2026 · Source: OSV.dev

Sep 10, 2017

1.0.1 unknown

1 CVE

CVE-2026-44983 GHSA-97wc-2hqc-cjgr May 09, 2026

smallbitvec: Integer overflow in safe API leads to heap buffer overflow

7.3 / 10

High

Local Low None None Unchanged Low Low High

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`

#![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

References

Updated Jun 08, 2026 · Source: OSV.dev

Sep 10, 2017

1.0.0 unknown

Sep 09, 2017

Activity

Details