smallbitvec CVE-2026-44983

Exploitation requires the application to accept attacker-controlled or attacker-influenced input that determines the capacity parameter passed to SmallBitVec construction or reservation methods (from_elem, with_capacity, reserve, or reserve_exact). The malicious capacity value must be close to usize::MAX (specifically, values where cap + bits_per_storage() - 1 overflows usize, approximately cap >= usize::MAX - 63 on typical platforms where bits_per_storage returns 64). The application must be compiled in release mode with default Rust overflow semantics (wrapping) rather than overflow-checks enabled. Exploitation is NOT limited to applications containing unsafe code blocks - the vulnerability manifests entirely through safe APIs, which is the defining characteristic making this severe in Rust's threat model. Limiting factors include: requires local attack vector or ability to influence application logic (cannot exploit remotely without application-level vulnerability accepting malicious capacity values), and the application must actually use the smallbitvec crate. Applications that only use smallbitvec with hardcoded or bounded capacity values are not exploitable.

The CVSS score of 7.3 (AV:L/AC:L/PR:N/UI:N/S:U/C:L/I:L/A:H) indicates local exploitation with low complexity and no privileges required, resulting in high availability impact and low confidentiality/integrity impact. However, real-world risk assessment reveals nuanced factors. The local attack vector (AV:L) significantly limits remote exploitation scenarios, requiring local code execution capability or the ability to influence application input to supply malicious capacity values. Attack complexity is genuinely low (AC:L) as demonstrated by two working proof-of-concept exploits requiring only standard API calls. No public exploit identified at time of analysis beyond the GitHub advisory POCs. EPSS data not provided, but the Rust ecosystem's rapid patching culture and cargo audit tooling typically limit widespread exploitation windows. The critical distinguishing factor is violation of Rust's memory safety model through safe APIs - this affects the trust model for Rust applications and could enable privilege escalation in sandboxed contexts that permit safe Rust but restrict unsafe code. The vulnerability is highly automatable for scanning (any code passing usize::MAX or near-maximum values to from_elem/reserve), but exploitation requires application logic that accepts attacker-controlled capacity parameters. No vendor-released patch identified at time of analysis - GitHub advisory confirms affected versions 1.0.1-2.6.0 with no fixed version listed, indicating active vulnerability in all current releases. Defenders should prioritize if applications use smallbitvec and accept external input for collection sizing.

An attacker with local code execution or the ability to influence application input supplies a malicious capacity parameter approaching usize::MAX to a SmallBitVec allocation function. For example, a web service using smallbitvec to cache bit flags per user might accept a malicious user_count parameter of usize::MAX - 10. When the application calls SmallBitVec::from_elem(malicious_capacity, false), the internal buffer_len calculation overflows, allocating only a tiny heap buffer while metadata records the massive logical capacity. Subsequent legitimate operations like v.set(attacker_controlled_index, true) perform out-of-bounds writes to arbitrary heap memory. The attacker achieves heap corruption through pure safe Rust APIs, potentially enabling control-flow hijacking, information disclosure from adjacent heap objects, or denial-of-service crashes, all while evading security mechanisms that restrict unsafe code.