RustSec flags rkyv panic-safety flaw, upgrade to 0.8.16

RustSec just turned a panic-safety bug in rkyv into a serious security warning: a failure in `InlineVec::clear` and `SerVec::clear` could climb all the way from a dropped element to memory corruption, denial of service, and possible code execution. The fix is rkyv 0.8.16, and anything earlier should be treated as urgent patch territory.

The flaw is brutally simple. Both `clear` paths walk the container, call `drop_in_place` on each element, and only then update `self.len`. If one element’s `Drop` implementation panics, the container can unwind while still believing those entries are present. The next time `clear()` runs, the code can revisit memory that has already been freed. In `InlineVec`, that second pass can happen later when the value itself is dropped. In `SerVec`, it can happen after the closure returns from `with_capacity`. RustSec says the bug is reachable entirely from safe Rust through `std::panic::catch_unwind`, so nobody needs unsafe code or special privileges to trigger it.

That makes this more than a theoretical cleanup bug. rkyv describes itself as a zero-copy deserialization framework for Rust, built for performance-sensitive code that wants to move data around without reflection-heavy overhead. That puts the crate in the same neighborhood as low-level serialization, storage, and data-pipeline code where panic behavior and memory layout matter a lot. The repository sits at about 4.2k stars, and the ecosystem around it includes crates like `rancor`, `bytecheck`, `rend`, and `ptr_meta`, so the blast radius is not just one helper type.

RustSec tied the fix to commit `5828cf5c27b664eb4432c4a93d4769e12e5e42fb`, and the advisory was reported on April 23, 2026 before being issued on May 11, 2026. The patched release is 0.8.16, and GitHub already shows `Cargo.toml` updated for that release. If your dependency tree still pulls an older rkyv, this is the kind of upgrade that should move from backlog to top priority.

The timing also fits a pattern RustSec has been watching closely. A separate April 2026 advisory for `thin-vec` flagged a similar panic-safety failure in `ThinVec::clear` and `IntoIter::drop`, where a panic during deallocation could lead to double free or use-after-free. For maintainers, the immediate check is straightforward: verify every code path that relies on `clear`, confirm you are on rkyv 0.8.16 or newer, and audit any `Drop` implementations that can panic inside serialization and deserialization flows. In this corner of Rust, cleanup code is now security code.