rkyv: Panic safety bugs in `InlineVec::clear` and `SerVec::clear` enable arbitrary code execution

CISA KEV lists vulnerabilities known to be exploited. FIRST EPSS estimates the likelihood of exploitation in the next 30 days. An unavailable score does not mean zero risk.

No exploitation or prediction data is available here for these CVEs. This does not mean they are safe or unlikely to be exploited.

`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 from `InlineVec`'s own `Drop` implementation when the value is later dropped. - `SerVec::clear()` is called again by `SerVec::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.

Source published

15 May 2026 18:09:10 UTC

Source modified

10 Sep 2026 03:50:47 UTC

Saved here

24 Oct 2026 13:19:54 UTC

Source terms

GitHub Advisory Database · CC-BY-4.0

Original source record · Cite this exact observation · Complete original publisher JSON

Source: osv · GitHub Advisory Database · CC-BY-4.0. The publisher's wording is preserved. ChangeIntel groups the information and labels changes. The JSON record includes additional source fields.

CVSS_V4 · CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:L/VA:L/SC:N/SI:N/SA:N

Publisher rating · MODERATE

`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 from `InlineVec`'s own `Drop` implementation when the value is later dropped. - `SerVec::clear()` is called again by `SerVec::with_capacity()` after the user closure returns. ## Impact - **CWE-415 (Double Free):** heap corruption when the element type is one that owns memory, such as `Box<T>` or `Vec<T>` - **CWE-416 (Use-After-Free):** memory corruption when an element is accessed following a caught panic Both types of undefined behavior can be invoked in safe Rust, but only if unwinding panics are enabled and `std::panic::catch_unwind` is used.

Source published

23 Apr 2026 12:00:00 UTC

Source modified

16 May 2026 07:08:02 UTC

Saved here

24 Oct 2026 13:19:54 UTC

Source terms

OSV · upstream source license applies

Original source record · Cite this exact observation · Complete original publisher JSON

Source: osv · OSV · upstream source license applies. The publisher's wording is preserved. ChangeIntel groups the information and labels changes. The JSON record includes additional source fields.