PT-2026-39707

Published

2026-04-23

·

Updated

2026-04-23

Description by

Score
N/A
Not available

No severity ratings or metrics are available. When they are, we'll update the corresponding info on the page.

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.
Vendors
Affected products
Related identifiers
RUSTSEC-2026-0122
Found an issue in the description? Have something to add? Feel free to write us 👾
dbugs@ptsecurity.com