GHSA-97WC-2HQC-CJGR

Vulnerability from github – Published: 2026-05-09 00:02 – Updated: 2026-05-09 00:02
VLAI
Summary
smallbitvec: Integer overflow in safe API leads to heap buffer overflow
Details

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
Severity
7.3 (High)
CVSS:3.1/AV:L/AC:L/PR:N/UI:N/S:U/C:L/I:L/A:H
Show details on source website
To clipboard 

{
  "affected": [
    {
      "package": {
        "ecosystem": "crates.io",
        "name": "smallbitvec"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "1.0.1"
            },
            {
              "last_affected": "2.6.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-44983"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-122",
      "CWE-190"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-05-09T00:02:47Z",
    "nvd_published_at": null,
    "severity": "HIGH"
  },
  "details": "### Summary\nAn 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.\n\n### Details\nThe issue originates from unchecked arithmetic in the internal helper function responsible for computing the required buffer size:\n\n```\n(cap + bits_per_storage() - 1) / bits_per_storage()\n```\n\nWhen `cap` is close to `usize::MAX`, the addition:\n\n```\ncap + bits_per_storage() - 1\n```\n\ncan overflow in release builds and wrap around due to Rust\u2019s default wrapping semantics for integer overflow in optimized builds.\n\nAs a result:\n- `buffer_len(cap)` may return a value significantly smaller than required.\n- The backing storage is allocated with insufficient size.\n- Internal metadata (logical length/capacity) reflects a much larger size than the actual allocation.\n\nSubsequent 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.\n\nSummary of the issue:\ninteger overflow\n\u2192 undersized allocation\n\u2192 inconsistent metadata (len/cap vs actual buffer)\n\u2192 unsafe internal access using corrupted metadata\n\u2192 heap buffer overflow (UB)\n### PoC\n#### PoC 1: Out-of-bounds write via `from_elem`\n```rust\n#![forbid(unsafe_code)]\n\nuse smallbitvec::SmallBitVec;\n\nfn main() {\n    // Triggers overflow in buffer_len(cap)\n    let mut v = SmallBitVec::from_elem(usize::MAX, false);\n\n    // Logical length is large, but backing storage is undersized\n    // This leads to out-of-bounds write in unsafe internals\n    v.set(0, true);\n}\n```\n#### PoC 2: Overflow via `reserve`\n```rust\n#![forbid(unsafe_code)]\n\nuse smallbitvec::SmallBitVec;\n\nfn main() {\n    let mut v = SmallBitVec::new();\n    v.push(true);\n\n    // Triggers overflow in capacity computation\n    v.reserve(usize::MAX - 10);\n}\n```\n\n### Impact\n- Heap buffer overflow via safe API only\n- ASAN-observable heap-buffer-overflow\n- Undefined Behavior detectable with Miri (e.g., out-of-bounds indexing due to corrupted metadata)\n\n### Tested on\n- rustc 1.96.0-nightly (9602bda1d 2026-04-05)\n- Target: x86_64-unknown-linux-gnu\n- Build: release\n- ASAN: `RUSTFLAGS=\"-Z sanitizer=address\" cargo +nightly run --release`\n- Miri: `cargo +nightly miri run --release`",
  "id": "GHSA-97wc-2hqc-cjgr",
  "modified": "2026-05-09T00:02:47Z",
  "published": "2026-05-09T00:02:47Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/servo/smallbitvec/security/advisories/GHSA-97wc-2hqc-cjgr"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/servo/smallbitvec"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:N/UI:N/S:U/C:L/I:L/A:H",
      "type": "CVSS_V3"
    }
  ],
  "summary": "smallbitvec: Integer overflow in safe API leads to heap buffer overflow"
}


Log in or create an account to share your comment.




Tags
Taxonomy of the tags.





Forecast uses a logistic model when the trend is rising, or an exponential decay model when the trend is falling. Fitted via linearized least squares.

Sightings

Author Source Type Date Other

Nomenclature

  • Seen: The vulnerability was mentioned, discussed, or observed by the user.
  • Confirmed: The vulnerability has been validated from an analyst's perspective.
  • Published Proof of Concept: A public proof of concept is available for this vulnerability.
  • Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
  • Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
  • Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
  • Not confirmed: The user expressed doubt about the validity of the vulnerability.
  • Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.


Detection rules are retrieved from Rulezet.