RUSTSEC-2026-0282: Double free in `AlignedBox<[T]>::realloc_with_default` when an element's `Drop` panics

What to do

1. See which version you have: cargo tree -i aligned_box (it also shows which of your dependencies pulls it in).
2. Update within your version requirement: cargo update -p aligned_box. If the fix is a newer major or minor than your requirement allows, raise it in Cargo.toml (for example aligned_box = "0.3.1") or update the dependency that pulls it in.
3. Check again with cargo audit, or paste your Cargo.lock into our Cargo.toml checker.

Details from the advisory

Shrinking an AlignedBox<[T]> takes ownership of the buffer out of self.container with ManuallyDrop::take, destroys the elements past the new length, and only then commits the new Box back into self.container. ManuallyDrop::take moves ownership but not the bits, so until that commit self.container still points at the original buffer.

T::drop runs inside the destruction loop and is user code , T carries no bound that would exclude a panicking Drop. If it unwinds, the commit is skipped and self.container is left pointing at the buffer whose tail has already been destroyed. AlignedBox's own destructor then reconstructs a Box from that pointer, drops every element again and deallocates , a double free (CWE-415) / use-after-free (CWE-416) reachable from safe Rust.

Growing the slice destroys nothing and is unaffected, as is realloc_with_value, which requires T: Copy and therefore a Drop that cannot run.

Mitigation

Update to 0.3.1.

References

• Package: crates.io/crates/aligned_box
• Advisory: rustsec.org/advisories/RUSTSEC-2026-0282.html
• Web: github.com/michaellass/aligned_box/pull/6

From the RustSec Advisory Database (CC0-1.0) via the OSV export, downloaded Oct 24, 2026. Severity score computed from the published CVSS vector.