Summary
rkyv: Panic safety bugs in InlineVec::clear and SerVec::clear enable arbitrary code execution
InlineVec::clear() and SerVec::clear() in rkyv were not panic-safe. Both functions iterate over their elements and call drop_in_place on each, updating self.len only after the loop. If an element's Drop implementation panics during the loop, self.len is left at its original value.
A subsequent invocation of clear() on the same container then re-visits the already-freed elements:
InlineVec::clear()is called again fromInlineVec's ownDropimplementation when the value is later dropped.SerVec::clear()is called again bySerVec::with_capacity()after the user closure returns.
Technical Impact
- CWE-415 (Double Free): Heap corruption when element type holds
Box<T> - CWE-416 (Use-After-Free): Memory corruption when element reads from heap during
Drop
Both vulnerabilities are triggerable entirely from safe Rust via std::panic::catch_unwind and require no special privileges.
Impact
Memory is accessed after it has been freed, leading to undefined behavior in native code. Typical impact: memory corruption, crash, or potential code execution.
Affected versions
Security releases
Kodem intelligence
Severity tells you how bad this could be in the worst case. It does not tell you whether you are exposed. Exploitability and impact are functions of runtime truth: whether the vulnerable code is present, reachable, and actually executes in your application. A vulnerable package can sit in your dependency tree and never run.
Kodem, an Intelligent Application Security platform, uses runtime intelligence to reveal which vulnerabilities actually execute in production, so teams prioritize the ones that genuinely matter. Kodem's runtime-powered SCA identifies whether this CVE is reachable in your applications.
Already deployed Kodem?
See it in your environmentNew to Kodem? Get a demo →Remediation advice
Kodem Kai can prioritize this vulnerability in your dependency tree and generate a fix recommendation.
Frequently Asked Questions
- What is GHSA-VFVV-C25P-M7MM? GHSA-VFVV-C25P-M7MM is a medium-severity use after free vulnerability in rkyv (rust), affecting versions >= 0.8.0, < 0.8.16. It is fixed in 0.8.16. Memory is accessed after it has been freed, leading to undefined behavior in native code.
- Which versions of rkyv are affected by GHSA-VFVV-C25P-M7MM? rkyv (rust) versions >= 0.8.0, < 0.8.16 is affected.
- Is there a fix for GHSA-VFVV-C25P-M7MM? Yes. GHSA-VFVV-C25P-M7MM is fixed in 0.8.16. Upgrade to this version or later.
- Is GHSA-VFVV-C25P-M7MM exploitable, and should I be worried? Whether GHSA-VFVV-C25P-M7MM is exploitable in your environment depends on whether the vulnerable code is present and reachable. A CVSS score is a worst-case rating; it does not account for your specific deployment, configuration, or usage patterns. Kodem, an Intelligent Application Security platform, uses runtime intelligence to show which vulnerabilities actually execute in production, so you can focus on the ones that represent real risk. Get a demo
- What actually determines whether GHSA-VFVV-C25P-M7MM is exploitable, and how bad it is? Exploitability and impact are not fixed properties of a CVE. They depend on runtime truth: whether the vulnerable code is present, reachable, and actually executes in your application. A high CVSS score on a dependency that never runs is not the same as real risk. Kodem, an Intelligent Application Security platform, uses runtime intelligence to reveal which vulnerabilities actually execute in production, so teams prioritize the ones that genuinely matter.
- How do I fix GHSA-VFVV-C25P-M7MM? Upgrade
rkyvto 0.8.16 or later.