GHSA-49hh-fprx-m68g is a low-severity (CVSS 2.5) Out-of-bounds Read vulnerability in vm-memory. A fix is available for vm-memory — see the affected versions and patch details below.
Default functions in VolatileMemory trait lack bounds checks, potentially leading to out-of-bounds memory accesses
Exploitation Status
No confirmed exploitation observed yet
- CISA’s own triage has not observed active exploitation or public proof-of-concept code for this CVE as of its last assessment.
Exploitation and automatability from CISA’s SSVC triage for GHSA-49hh-fprx-m68g.
EPSS Exploitation Probability
Probability of exploitation in the next 30 days, from FIRST.org EPSS.
How urgent is this, really
GHSA-49hh-fprx-m68g by exploitation likelihood (EPSS) against impact (CVSS). Outside the shaded patch-first corner.
Where this sits among everything scored
Of 379,842 CVEs with a current EPSS score, this one falls in the < 10% band (highlighted). Counts from FIRST.org, log-scaled.
Real-World Exposure
vm-memoryReal-time download stats are indexed for npm and PyPI packages. This vulnerability affects crates.io packages — download data is not available via public APIs for these ecosystems.
Description
In a typical Virtual Machine Monitor (VMM) there are several components, such as boot loader, virtual device drivers, virtio backend drivers and vhost drivers, that need to access the VM physical memory. The vm-memory rust crate provides a set of traits to decouple VM memory consumers from VM memory providers. An issue was discovered in the default implementations of the VolatileMemory::{get_atomic_ref, aligned_as_ref, aligned_as_mut, get_ref, get_array_ref} trait functions, which allows out-of-bounds memory access if the VolatileMemory::get_slice function returns a VolatileSlice whose length is less than the function’s count argument. No implementations of get_slice provided in vm_memory are affected. Users of custom VolatileMemory implementations may be impacted if the custom implementation does not adhere to get_slice's documentation. The issue started in version 0.1.0 but was fixed in version 0.12.2 by inserting a check that verifies that the VolatileSlice returned by get_slice is of the correct length. Users are advised to upgrade. There are no known workarounds for this issue.
Affected Packages
| Ecosystem | Package | Vulnerable range | Fix |
|---|---|---|---|
| 🦀crates.io | vm-memory | all versions | 0.12.2cargo update -p vm-memory --precise 0.12.2 |
Affected Products
vm-memoryvm-memory_projectDetection & mitigation playbook
Open-source dependencyDetect
Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for vm-memory, including transitive dependencies — a direct dependency you never call can still pull in a vulnerable version.
Fix
Update vm-memory to 0.12.2 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms GHSA-49hh-fprx-m68g is resolved across your whole dependency graph.
Workarounds
Stop feeding it untrusted input: reject or quarantine files and payloads from unverified sources until you can upgrade, restrict accepted formats to the ones you actually need, and run the parsing or decoding step in a least-privileged sandbox or short-lived worker so a crash or corrupted read cannot reach the rest of the process.
Frequently Asked Questions
Is GHSA-49hh-fprx-m68g in your dependencies?
Find it across crates.io, including transitive dependencies.