Crossbeam-channel: crossbeam-channel vulnerable to double free on drop

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.

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.

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](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

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