panic safety bug may happen in 3 functions

[JOE1994]

Hello :crab: , we (Rust group @sslab-gatech) found a memory-safety/soundness issue in this crate while scanning Rust code on crates.io for potential vulnerabilities.

Issue Description

• common::Slice::<T, H>::new Drop uninitialized memory upon panic within T::default(). https://github.com/ibabushkin/arenavec/blob/f931efb96ffe85a6433eb1861b698ad38515e427/src/common.rs#L73-L89
• common::SliceVec::<T, H>::resize_with double free upon panic within T::drop in line 438. https://github.com/ibabushkin/arenavec/blob/f931efb96ffe85a6433eb1861b698ad38515e427/src/common.rs#L417-L443
• common::SliceVec::<T, H>::resize double free upon panic within T::drop in line 466. https://github.com/ibabushkin/arenavec/blob/f931efb96ffe85a6433eb1861b698ad38515e427/src/common.rs#L445-L471

  Proof of Concept

  Example program below exhibits a double drop on the same object.

  
  // tested with rustc 1.50.0-nightly (7f9c43cf9 2020-12-23) on Ubuntu 18.04
  use arenavec::rc::{Arena, SliceVec};
  use arenavec::ArenaBacking;
  use std::sync::atomic::{
  AtomicBool,
  Ordering::SeqCst,
  };

[derive(Clone)]

struct Foo(usize, Option); impl Drop for Foo { fn drop(&mut self) { println!("Dropping {:?}", self.0); if self.0 == 1 && ATOMIC_TRUE.compare_and_swap(true, false, SeqCst) { println!("THIS WILL PANIC {:?}", self.1.as_ref().unwrap()); } } }

static ATOMIC_TRUE: AtomicBool = AtomicBool::new(true); const DEFAULT_CAPACITY: usize = 4096 << 8; fn main() { let arena = Arena::init_capacity(ArenaBacking::SystemAllocation, DEFAULT_CAPACITY).unwrap();

let mut vec: SliceVec<Foo> = SliceVec::new(arena.inner());
vec.push(Foo(0, Some(12)));
vec.push(Foo(1, None));
assert_eq!(vec.len(), 2);

vec.resize(1, Foo(99, Some(78)));

}

#### Program Output
The message `Dropping 1` is printed twice, indicating the same object was dropped twice.

Dropping 1 thread 'main' panicked at 'called Option::unwrap() on a None value', examples/arenavec.rs:14:62 note: run with RUST_BACKTRACE=1 environment variable to display a backtrace Dropping 99 Dropping 0 Dropping 1

## Suggested Fix
* `common::Slice::<T, H>::new`:
  Move `res.len = len;` to after all writes are done.
* `common::SliceVec::<T, H>::resize_with` & `common::SliceVec::<T, H>::resize`:
  Move `self.slice.len = len;` to before `drop_in_place()`.

Thank you for checking out this issue!

[Shnatsel]

Heads up: this issue has been included in the RustSec advisory database. It will be surfaced by tools such as cargo-audit or cargo-deny from now on.

Once a fix is released to crates.io, please open a pull request to update the advisory with the patched version, or file an issue on the advisory database repository.