crossbeam-channel: double free on Drop
| Details |
|
| Package |
crossbeam-channel |
| Version |
0.5.14 |
| URL |
crossbeam-rs/crossbeam#1187 |
| Date |
2025-04-08 |
| Patched versions |
>=0.5.15 |
| Unaffected versions |
<=0.5.11 |
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 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
See advisory page for additional details.
crossbeam-channel0.5.14>=0.5.15<=0.5.11The internal
Channeltype'sDropmethod has a racewhich 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_messagescontained two paths that could lead tohead.blockbeing read but only one of them would swap the value. This meant thatdicard_all_messagescould end up observing a non-null block pointer (and therefore attempting to free it) without settinghead.blockto null. This would then lead toChannel::dropmaking 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
See advisory page for additional details.