Package Instance

crossbeam-channel Vulnerable to Double Free on Drop
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](https://github.com/crossbeam-rs/crossbeam/pull/1187#issue-2980761131):

> 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 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](https://github.com/crossbeam-rs/crossbeam/pull/1084),
first published in 0.5.12.

The fix is in
upstream [MR \#1187](https://github.com/crossbeam-rs/crossbeam/pull/1187)
and has been published in 0.5.15

crossbeam-channel Undefined Behavior before v0.4.4
### Impact

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 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.

Incorrect buffer size in crossbeam-channel
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 with the number of iterator elements.