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
4 actionable advisories, newest first. Withdrawn advisories and news are excluded. Coverage is partial.
The internal Channel type's Drop method has a race which could, in some circumstances, lead to a double-free. This could result in memory corruption. Quoting from the upstream description in merge request \#1187: The problem lies in the fact that dicardallmessages contained two paths that could lead to head.block being read but only one of them would swap the value. This meant that dicardallmessages could end up observing a non-null block pointer (and therefore attempting to free it) without setting head.block to null. This would then lead to Channel::drop making a second attempt at dropping the same pointer. The bug was introduced while fixing a memory leak, in upstream MR \#1084, first published in 0.5.12. The fix is in upstream MR \#1187 and has been published in 0.5.15
Recommended action: Upgrade to 0.5.15 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::zeroed() 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). The flaw was corrected by avoiding the use of mem::zeroed(), using MaybeUninit instead.
Recommended action: Upgrade to 0.4.3 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact The affected version of this crate's the bounded channel incorrectly assumes that Vec::fromiter has allocated capacity that same as the number of iterator elements. Vec::fromiter does not actually guarantee that and may allocate extra memory. The destructor of the bounded channel reconstructs Vec from the raw pointer based on the incorrect assumes described above. This is unsound and causing deallocation with the incorrect capacity when Vec::fromiter has allocated different sizes with the number of iterator elements. Patches This has been fixed in crossbeam-channel 0.4.4. We recommend users to upgrade to 0.4.4. References See https://github.com/crossbeam-rs/crossbeam/pull/533, https://github.com/crossbeam-rs/crossbeam/issues/539, and https://github.com/RustSec/advisory-db/pull/425 for more details. License This advisory is in the public domain.
Recommended action: Upgrade to 0.4.4 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
The affected version of this crate's the bounded channel incorrectly assumes that Vec::fromiter has allocated capacity that same as the number of iterator elements. Vec::fromiter does not actually guarantee that and may allocate extra memory. The destructor of the bounded channel reconstructs Vec from the raw pointer based on the incorrect assumes described above. This is unsound and causing deallocation with the incorrect capacity when Vec::fromiter has allocated different sizes with the number of iterator elements.
Recommended action: Upgrade to 0.4.4 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.