rustsec-2025-0170
Vulnerability from osv_rustsec
Published
2025-04-24 12:00
Modified
2026-08-12 09:44
Summary
`hugepage_rs::dealloc` may allow invalid memory deallocation from safe code
Details

hugepage_rs::dealloc was a publicly accessible safe function. It accepted an arbitrary raw pointer and Layout, then forwarded them to the hugepage allocator's GlobalAlloc::dealloc implementation.

GlobalAlloc::dealloc requires callers to ensure that the pointer denotes a block of memory currently allocated by the allocator and that the layout is the same layout used for the allocation. The safe wrapper neither verified these requirements nor marked them as unsafe preconditions for callers.

Affected versions therefore allowed safe Rust code to call dealloc with an invalid pointer, a pointer not allocated by the hugepage allocator, or an incorrect layout, which could cause undefined behavior.

The upstream repository fixed this in version 0.1.1 by marking dealloc as unsafe and documenting the caller's safety requirements.

References
To clipboard 

{
  "affected": [
    {
      "database_specific": {
        "categories": [
          "memory-corruption"
        ],
        "cvss": null,
        "informational": "unsound"
      },
      "ecosystem_specific": {
        "affected_functions": null,
        "affects": {
          "arch": [],
          "functions": [
            "hugepage_rs::dealloc"
          ],
          "os": []
        }
      },
      "package": {
        "ecosystem": "crates.io",
        "name": "hugepage-rs",
        "purl": "pkg:cargo/hugepage-rs"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0.0.0-0"
            },
            {
              "fixed": "0.1.1"
            }
          ],
          "type": "SEMVER"
        }
      ],
      "versions": []
    }
  ],
  "aliases": [],
  "database_specific": {
    "license": "CC0-1.0"
  },
  "details": "`hugepage_rs::dealloc` was a publicly accessible safe function. It accepted an arbitrary raw pointer and `Layout`, then forwarded them to the hugepage allocator\u0027s `GlobalAlloc::dealloc` implementation.\n\n`GlobalAlloc::dealloc` requires callers to ensure that the pointer denotes a block of memory currently allocated by the allocator and that the layout is the same layout used for the allocation. The safe wrapper neither verified these requirements nor marked them as\nunsafe preconditions for callers.\n\nAffected versions therefore allowed safe Rust code to call `dealloc` with an invalid pointer, a pointer not allocated by the hugepage allocator, or an incorrect layout, which could cause undefined behavior.\n\nThe upstream repository fixed this in version `0.1.1` by marking `dealloc` as unsafe and documenting the caller\u0027s safety requirements.",
  "id": "RUSTSEC-2025-0170",
  "modified": "2026-08-12T09:44:47Z",
  "published": "2025-04-24T12:00:00Z",
  "references": [
    {
      "type": "PACKAGE",
      "url": "https://crates.io/crates/hugepage-rs"
    },
    {
      "type": "ADVISORY",
      "url": "https://rustsec.org/advisories/RUSTSEC-2025-0170.html"
    },
    {
      "type": "REPORT",
      "url": "https://github.com/cppcoffee/hugepage-rs/issues/5"
    },
    {
      "type": "WEB",
      "url": "https://github.com/cppcoffee/hugepage-rs/pull/6"
    },
    {
      "type": "WEB",
      "url": "https://github.com/cppcoffee/hugepage-rs/commit/2b30bdf227f39b1c9ed7af16ea0cc3957f88da18"
    }
  ],
  "related": [],
  "severity": [],
  "summary": "`hugepage_rs::dealloc` may allow invalid memory deallocation from safe code"
}



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.