smallvec known bugs

Affected versions of this crate called mem::uninitialized() to create values of a user-supplied type T. This is unsound e.g. if T is a reference type (which must be non-null and thus may not remain uninitialized). The flaw was corrected by avoiding the use of mem::uninitialized(), using MaybeUninit instead.

A bug in the `SmallVec::insert_many` method caused it to allocate a buffer that was smaller than needed. It then wrote past the end of the buffer, causing a buffer overflow and memory corruption on the heap. This bug was only triggered if the iterator passed to `insert_many` yielded more items than the lower bound returned from its `size_hint` method. The flaw was corrected in smallvec 0.6.14 and 1.6.1, by ensuring that additional space is always reserved for each item inserted. The fix also simplified the implementation of `insert_many` to use less unsafe code, so it is easier to verify its correctness. Thank you to Yechan Bae (@Qwaz) and the Rust group at Georgia Tech’s SSLab for finding and reporting this bug.

Attempting to call `grow` on a spilled SmallVec with a value less than the current capacity causes corruption of memory allocator data structures. An attacker that controls the value passed to `grow` may exploit this flaw to obtain memory contents or gain remote code execution. Credits to @ehuss for discovering, reporting and fixing the bug.

Attempting to call `grow` on a spilled SmallVec with a value equal to the current capacity causes it to free the existing data. This performs a double free immediately and may lead to use-after-free on subsequent accesses to the SmallVec contents. An attacker that controls the value passed to `grow` may exploit this flaw to obtain memory contents or gain remote code execution. Credits to @ehuss for discovering, reporting and fixing the bug.

Affected versions of this crate called `mem::uninitialized()` to create values of a user-supplied type `T`. This is unsound e.g. if `T` is a reference type (which must be non-null and thus may not remain uninitialized). The flaw was corrected by avoiding the use of `mem::uninitialized()`, using `MaybeUninit` instead.

If an iterator passed to `SmallVec::insert_many` panicked in `Iterator::next`, destructors were run during unwinding while the vector was in an inconsistent state, possibly causing a double free (a destructor running on two copies of the same value). This is fixed in smallvec 0.6.3 by ensuring that the vector's length is not updated to include moved items until they have been removed from their original positions. Items may now be leaked if `Iterator::next` panics, but they will not be dropped more than once. Thank you to @Vurich for reporting this bug.

Affected versions of this crate called `mem::uninitialized()` to create values of a user-supplied type `T`. This is unsound e.g. if `T` is a reference type (which must be non-null and thus may not remain uninitialized). The flaw was corrected by avoiding the use of `mem::uninitialized()`, using `MaybeUninit` instead.

If an iterator passed to SmallVec::insert_many panicked in Iterator::next, destructors were run during unwinding while the vector was in an inconsistent state, possibly causing a double free (a destructor running on two copies of the same value). This is fixed in smallvec 0.6.3 by ensuring that the vector's length is not updated to include moved items until they have been removed from their original positions. Items may now be leaked if Iterator::next panics, but they will not be dropped more than once.

Attempting to call grow on a spilled SmallVec with a value equal to the current capacity causes it to free the existing data. This performs a double free immediately and may lead to use-after-free on subsequent accesses to the SmallVec contents. An attacker that controls the value passed to grow may exploit this flaw to obtain memory contents or gain remote code execution.

Attempting to call grow on a spilled SmallVec with a value less than the current capacity causes corruption of memory allocator data structures. An attacker that controls the value passed to grow may exploit this flaw to obtain memory contents or gain remote code execution.

A bug in the SmallVec::insert_many method caused it to allocate a buffer that was smaller than needed. It then wrote past the end of the buffer, causing a buffer overflow and memory corruption on the heap. This bug was only triggered if the iterator passed to insert_many yielded more items than the lower bound returned from its size_hint method. The flaw was corrected in smallvec 0.6.14 and 1.6.1, by ensuring that additional space is always reserved for each item inserted. The fix also simplified the implementation of insert_many to use less unsafe code, so it is easier to verify its correctness.