crossbeam-channel: prevent double free on Drop
#1187
Merged
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This PR is fixing a regression introduced by crossbeam-rs#1084 that can lead to a double free when dropping the channel. The method `Channel::discard_all_messages` has the property that if it observes `head.block` pointing to a non-null pointer it will attempt to free it. The same property holds for the `Channel::drop` method and so it is critical that whenever `head.block` is freed it must also be set to a null pointer so that it is freed exactly once. Before crossbeam-rs#1084 the behavior of `discard_all_messages` ensured `head.block` was `null` after its execution due to the atomic store right before exiting [1]. After crossbeam-rs#1084 `discard_all_messages` atomically swaps the current value of `head.block` with a null pointer at the moment the value is read instead of waiting for the end of the function. 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 is similar to the one previously fixed by crossbeam-rs#972 and the double free can be reproduced by reverting the reproduction commit from that PR [2]. As with crossbeam-rs#972 it is quite difficult to trigger this bug without introducing artificial sleeps in critical points so this PR does not include a test. [1] https://github.com/crossbeam-rs/crossbeam/blob/crossbeam-channel-0.5.11/crossbeam-channel/src/flavors/list.rs#L625 [2] crossbeam-rs@2d22628 Signed-off-by: Petros Angelatos <petrosagg@gmail.com>
taiki-e
pushed a commit
that referenced
this pull request
Apr 8, 2025
This PR is fixing a regression introduced by #1084 that can lead to a double free when dropping the channel. The method `Channel::discard_all_messages` has the property that if it observes `head.block` pointing to a non-null pointer it will attempt to free it. The same property holds for the `Channel::drop` method and so it is critical that whenever `head.block` is freed it must also be set to a null pointer so that it is freed exactly once. Before #1084 the behavior of `discard_all_messages` ensured `head.block` was `null` after its execution due to the atomic store right before exiting [1]. After #1084 `discard_all_messages` atomically swaps the current value of `head.block` with a null pointer at the moment the value is read instead of waiting for the end of the function. 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 is similar to the one previously fixed by #972 and the double free can be reproduced by reverting the reproduction commit from that PR [2]. As with #972 it is quite difficult to trigger this bug without introducing artificial sleeps in critical points so this PR does not include a test. [1] https://github.com/crossbeam-rs/crossbeam/blob/crossbeam-channel-0.5.11/crossbeam-channel/src/flavors/list.rs#L625 [2] 2d22628 Signed-off-by: Petros Angelatos <petrosagg@gmail.com>
taiki-e
pushed a commit
that referenced
this pull request
Apr 8, 2025
This PR is fixing a regression introduced by #1084 that can lead to a double free when dropping the channel. The method `Channel::discard_all_messages` has the property that if it observes `head.block` pointing to a non-null pointer it will attempt to free it. The same property holds for the `Channel::drop` method and so it is critical that whenever `head.block` is freed it must also be set to a null pointer so that it is freed exactly once. Before #1084 the behavior of `discard_all_messages` ensured `head.block` was `null` after its execution due to the atomic store right before exiting [1]. After #1084 `discard_all_messages` atomically swaps the current value of `head.block` with a null pointer at the moment the value is read instead of waiting for the end of the function. 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 is similar to the one previously fixed by #972 and the double free can be reproduced by reverting the reproduction commit from that PR [2]. As with #972 it is quite difficult to trigger this bug without introducing artificial sleeps in critical points so this PR does not include a test. [1] https://github.com/crossbeam-rs/crossbeam/blob/crossbeam-channel-0.5.11/crossbeam-channel/src/flavors/list.rs#L625 [2] 2d22628 Signed-off-by: Petros Angelatos <petrosagg@gmail.com>
|
Published in crossbeam-channel 0.5.15. |
5 tasks
|
FTR, I'm preparing a RUSTSEC advisory. |
|
@taiki-e I mentioned you in the advisory PR because we like to get sign-off from a maintainer before merging an advisory. Not sure if you've seen it? |
|
Approved.
By the way, I love this. If NVD CPE team had such a policy, we would not have had problems like github/advisory-database#5064 (comment)... |
This was referenced Apr 10, 2025
Open
|
Red Hat CNA is available to reserve a CVE for this if you would like. |
facebook-github-bot
pushed a commit
to facebookincubator/reindeer
that referenced
this pull request
Apr 12, 2025
… Drop Package: crossbeam-channel 0.5.14 Summary: VULNERABILITY RUSTSEC-2025-0024 - 2025-04-08: crossbeam-channel: double free on Drop Package: crossbeam-channel 0.5.14 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](crossbeam-rs/crossbeam#1187 (comment)): > 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](crossbeam-rs/crossbeam#1084), first published in 0.5.12. The fix is in upstream [MR \#1187](crossbeam-rs/crossbeam#1187) and has been published in 0.5.15 Reviewed By: dtolnay Differential Revision: D72915462 fbshipit-source-id: c53113f91eedf478646588a84d0fa3aa85a6d2a0
facebook-github-bot
pushed a commit
to facebook/pyrefly
that referenced
this pull request
Apr 12, 2025
… Drop Package: crossbeam-channel 0.5.14 Summary: VULNERABILITY RUSTSEC-2025-0024 - 2025-04-08: crossbeam-channel: double free on Drop Package: crossbeam-channel 0.5.14 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](crossbeam-rs/crossbeam#1187 (comment)): > 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](crossbeam-rs/crossbeam#1084), first published in 0.5.12. The fix is in upstream [MR \#1187](crossbeam-rs/crossbeam#1187) and has been published in 0.5.15 Reviewed By: dtolnay Differential Revision: D72915462 fbshipit-source-id: c53113f91eedf478646588a84d0fa3aa85a6d2a0
facebook-github-bot
pushed a commit
to facebook/hhvm
that referenced
this pull request
Apr 12, 2025
… Drop Package: crossbeam-channel 0.5.14 Summary: VULNERABILITY RUSTSEC-2025-0024 - 2025-04-08: crossbeam-channel: double free on Drop Package: crossbeam-channel 0.5.14 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](crossbeam-rs/crossbeam#1187 (comment)): > 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](crossbeam-rs/crossbeam#1084), first published in 0.5.12. The fix is in upstream [MR \#1187](crossbeam-rs/crossbeam#1187) and has been published in 0.5.15 Reviewed By: dtolnay Differential Revision: D72915462 fbshipit-source-id: c53113f91eedf478646588a84d0fa3aa85a6d2a0
This was referenced Apr 13, 2025
matthiaskrgr
added a commit
to matthiaskrgr/rust
that referenced
this pull request
Apr 17, 2025
…alfJung,tgross35 sync::mpsc: prevent double free on `Drop` This PR is fixing a regression introduced by rust-lang#121646 that can lead to a double free when dropping the channel. The details of the bug can be found in the corresponding crossbeam PR crossbeam-rs/crossbeam#1187
matthiaskrgr
added a commit
to matthiaskrgr/rust
that referenced
this pull request
Apr 17, 2025
…alfJung,tgross35 sync::mpsc: prevent double free on `Drop` This PR is fixing a regression introduced by rust-lang#121646 that can lead to a double free when dropping the channel. The details of the bug can be found in the corresponding crossbeam PR crossbeam-rs/crossbeam#1187
matthiaskrgr
added a commit
to matthiaskrgr/rust
that referenced
this pull request
Apr 18, 2025
…alfJung,tgross35 sync::mpsc: prevent double free on `Drop` This PR is fixing a regression introduced by rust-lang#121646 that can lead to a double free when dropping the channel. The details of the bug can be found in the corresponding crossbeam PR crossbeam-rs/crossbeam#1187
rust-timer
added a commit
to rust-lang-ci/rust
that referenced
this pull request
Apr 18, 2025
Rollup merge of rust-lang#139553 - petrosagg:channel-double-free, r=RalfJung,tgross35 sync::mpsc: prevent double free on `Drop` This PR is fixing a regression introduced by rust-lang#121646 that can lead to a double free when dropping the channel. The details of the bug can be found in the corresponding crossbeam PR crossbeam-rs/crossbeam#1187
cuviper
pushed a commit
to cuviper/rust
that referenced
this pull request
Apr 18, 2025
This PR is fixing a regression introduced by rust-lang#121646 that can lead to a double free when dropping the channel. The details of the bug can be found in the corresponding crossbeam PR crossbeam-rs/crossbeam#1187 Signed-off-by: Petros Angelatos <petrosagg@gmail.com> (cherry picked from commit b9e2ac5)
github-actions bot
pushed a commit
to rust-lang/miri
that referenced
this pull request
Apr 19, 2025
This PR is fixing a regression introduced by #121646 that can lead to a double free when dropping the channel. The details of the bug can be found in the corresponding crossbeam PR crossbeam-rs/crossbeam#1187 Signed-off-by: Petros Angelatos <petrosagg@gmail.com>
github-actions bot
pushed a commit
to rust-lang/miri
that referenced
this pull request
Apr 19, 2025
…gross35 sync::mpsc: prevent double free on `Drop` This PR is fixing a regression introduced by #121646 that can lead to a double free when dropping the channel. The details of the bug can be found in the corresponding crossbeam PR crossbeam-rs/crossbeam#1187
github-actions bot
pushed a commit
to model-checking/verify-rust-std
that referenced
this pull request
Apr 19, 2025
This PR is fixing a regression introduced by rust-lang#121646 that can lead to a double free when dropping the channel. The details of the bug can be found in the corresponding crossbeam PR crossbeam-rs/crossbeam#1187 Signed-off-by: Petros Angelatos <petrosagg@gmail.com>
github-actions bot
pushed a commit
to model-checking/verify-rust-std
that referenced
this pull request
Apr 19, 2025
…alfJung,tgross35 sync::mpsc: prevent double free on `Drop` This PR is fixing a regression introduced by rust-lang#121646 that can lead to a double free when dropping the channel. The details of the bug can be found in the corresponding crossbeam PR crossbeam-rs/crossbeam#1187
tavianator
added a commit
to sharkdp/fd
that referenced
this pull request
Apr 29, 2025
To grab a double-free fix. Link: crossbeam-rs/crossbeam#1187
yoctocell
pushed a commit
to yoctocell/miri
that referenced
this pull request
Apr 30, 2025
This PR is fixing a regression introduced by #121646 that can lead to a double free when dropping the channel. The details of the bug can be found in the corresponding crossbeam PR crossbeam-rs/crossbeam#1187 Signed-off-by: Petros Angelatos <petrosagg@gmail.com>
hcldan
added a commit
to hcldan/tracing
that referenced
this pull request
Apr 30, 2025
Upgrade to avoid the double free on drop Refs: crossbeam-rs/crossbeam#1187
hcldan
added a commit
to hcldan/tracing
that referenced
this pull request
Apr 30, 2025
Upgrade to avoid the double free on drop Refs: crossbeam-rs/crossbeam#1187
hcldan
added a commit
to hcldan/tracing
that referenced
this pull request
Apr 30, 2025
Upgrade to avoid the double free on drop Refs: crossbeam-rs/crossbeam#1187
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This PR is fixing a regression introduced by #1084 that can lead to a double free when dropping the channel.
The method
Channel::discard_all_messageshas the property that if it observeshead.blockpointing to a non-null pointer it will attempt to free it.The same property holds for the
Channel::dropmethod and so it is critical that wheneverhead.blockis freed it must also be set to a null pointer so that it is freed exactly once.Before #1084 the behavior of
discard_all_messagesensuredhead.blockwasnullafter its execution due to the atomic store right before exiting [1].After #1084
discard_all_messagesatomically swaps the current value ofhead.blockwith a null pointer at the moment the value is read instead of waiting for the end of the function.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 is similar to the one previously fixed by #972 and the double free can be reproduced by reverting the reproduction commit from that PR [2].
As with #972 it is quite difficult to trigger this bug without introducing artificial sleeps in critical points so this PR does not include a test.
[1] https://github.com/crossbeam-rs/crossbeam/blob/crossbeam-channel-0.5.11/crossbeam-channel/src/flavors/list.rs#L625
[2] 2d22628