Open actionable advisories and recorded vendor fixes. This public package view has no inventory attached and cannot establish whether your deployment is affected. A vendor fix never resolves your finding; verify your installed version and the source guidance.
Open advisories
6 actionable advisories, newest first. Withdrawn advisories and news are excluded. Coverage is partial.
A bug in the SmallVec::insertmany 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 insertmany yielded more items than the lower bound returned from its sizehint 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 insertmany to use less unsafe code, so it is easier to verify its correctness.
Recommended action: Upgrade to 1.6.1 or 0.6.14 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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.
Recommended action: Upgrade to 0.6.13 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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.
Recommended action: Upgrade to 0.6.13 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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.
Recommended action: Upgrade to 0.6.10 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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.
Recommended action: Upgrade to 0.6.10 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
If an iterator passed to SmallVec::insertmany 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.
Recommended action: Upgrade to 0.6.3 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.