-
Notifications
You must be signed in to change notification settings - Fork 369
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add advisory for UB in crossbeam-channel 0.4.3 #425
Conversation
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 |
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. |
Merging. Thanks! |
Update crossbeam-channel to avoid UB More info: rustsec/advisory-db#425
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.
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.
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.
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.
The affected version of this crate's the
bounded
channel incorrectly assumes thatVec::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 thebounded
channel reconstructsVec
from the raw pointer based on the incorrect assumes described above. This is unsound and causing deallocation with the incorrect capacity whenVec::from_iter
has 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.)