Add advisory for UB in crossbeam-channel 0.4.3 - #425
Merged
Merged
Conversation
Member
|
Thanks for the report! Is this purely theoretical at this point, or has deallocation of the incorrect size has actually been observed in practice? If it's the latter, I'd drop Last time I checked |
Contributor
Author
It has actually been observed in practice (https://twitter.com/khuey_/status/1311641831201857537, nervosnetwork/ckb#2244), so I'll drop
If the number of elements is small, it seems that 0-7 extra capacity is allocated depending on the size of the elements. |
Member
|
Merging. Thanks! |
bors
added a commit
to rust-lang-ci/rust
that referenced
this pull request
Oct 12, 2020
Update crossbeam-channel to avoid UB More info: rustsec/advisory-db#425
CjS77
added a commit
to tari-project/broadcast_channel
that referenced
this pull request
Jun 7, 2022
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 crossbeam-rs/crossbeam#533, crossbeam-rs/crossbeam#539, and rustsec/advisory-db#425 for more details.
CjS77
added a commit
to tari-project/broadcast_channel
that referenced
this pull request
Jun 7, 2022
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 crossbeam-rs/crossbeam#533, crossbeam-rs/crossbeam#539, and rustsec/advisory-db#425 for more details.
CjS77
added a commit
to tari-project/broadcast_channel
that referenced
this pull request
Jun 7, 2022
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 crossbeam-rs/crossbeam#533, crossbeam-rs/crossbeam#539, and rustsec/advisory-db#425 for more details.
CjS77
added a commit
to tari-project/broadcast_channel
that referenced
this pull request
Jun 7, 2022
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 crossbeam-rs/crossbeam#533, crossbeam-rs/crossbeam#539, and rustsec/advisory-db#425 for more details.
4 tasks
north-echo
added a commit
to north-echo/advisory-db
that referenced
this pull request
Aug 13, 2026
Eleven decode paths in the TDS client respond to server-controlled values with panic!, unimplemented!, todo! or unwrap() on None rather than returning Err. Three are in PRELOGIN, so they are reachable pre-auth and pre-TLS. Reported publicly as tiberius-rs/tiberius#424 and rustsec#425 on 2026-07-29 with no maintainer response since.
north-echo
added a commit
to north-echo/advisory-db
that referenced
this pull request
Aug 13, 2026
Eleven decode paths in the TDS client respond to server-controlled values with panic!, unimplemented!, todo! or unwrap() on None rather than returning Err. Three are in PRELOGIN, so they are reachable pre-auth and pre-TLS. Reported publicly as tiberius-rs/tiberius#424 and rustsec#425 on 2026-07-29 with no maintainer response since. Assisted-by: Claude <noreply@anthropic.com>
north-echo
added a commit
to north-echo/advisory-db
that referenced
this pull request
Sep 18, 2026
The repo moved to the tiberius-rs org and gained a new maintainer team. PRs rustsec#440 and rustsec#441 merged and close seven of the eleven sites. Issues rustsec#424 and rustsec#425 were closed as fixed by rustsec#440, but four sites are still present on the development branch, verified against feb8df2 in a release build: token_row.rs decode and decode_nbc, type_info.rs for SSVariant and Udt, and the bare assert! in token_env_change.rs. Patches for those four are in the unmerged rustsec#443, sequenced behind a breaking change in rustsec#442. No release has been cut, so patched stays empty and every published version is affected by all eleven. Drops the stale claim that no maintainer had responded, and retargets the links from prisma/tiberius to tiberius-rs/tiberius. Assisted-by: Claude <noreply@anthropic.com>
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
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
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.
The affected version of this crate's the
boundedchannel incorrectly assumes thatVec::from_iterhas allocated capacity that same as the number of iterator elements.Vec::from_iterdoes not actually guarantee that and may allocate extra memory. The destructor of theboundedchannel reconstructsVecfrom the raw pointer based on the incorrect assumes described above. This is unsound and causing deallocation with the incorrect capacity whenVec::from_iterhas allocated different sizes with the number of iterator elements.Refs: crossbeam-rs/crossbeam#533, crossbeam-rs/crossbeam#539 (Both issues are mainly saying about crossbeam-queue, but crossbeam-queue including this UB, has not been released and only crossbeam-channel is affected.)