Duplicate Advisory This advisory has been withdrawn because it is a duplicate of GHSA-pg9f-39pc-qf8g. This link is maintained to preserve external references. Original Description In crossbeam-channel rust crate, the internal Channel type's Drop method has a race condition which could, in some circumstances, lead to a double-free that could result in memory corruption.
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 dicard_all_messages contained two paths that could lead to head.block being read but only one of them would swap the value. This meant that dicard_all_messages could end up observing a non-null …
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 dicard_all_messages contained two paths that could lead to head.block being read but only one of them would swap the value. This meant that dicard_all_messages could end up observing a non-null …
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.
The affected version of this crate's the bounded channel incorrectly assumes that Vec::from_iter has allocated capacity that same as the number of iterator elements. Vec::from_iter 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::from_iter has allocated different sizes …
The affected version of this crate's the bounded channel incorrectly assumes that Vec::from_iter has allocated capacity that same as the number of iterator elements. Vec::from_iter 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::from_iter has allocated different sizes …