Show filters
5 Total Results
Displaying 1-5 of 5
Sort by:
Attacker Value
Unknown

CVE-2022-23639

Disclosure Date: February 15, 2022 (last updated October 07, 2023)
crossbeam-utils provides atomics, synchronization primitives, scoped threads, and other utilities for concurrent programming in Rust. crossbeam-utils prior to version 0.8.7 incorrectly assumed that the alignment of `{i,u}64` was always the same as `Atomic{I,U}64`. However, the alignment of `{i,u}64` on a 32-bit target can be smaller than `Atomic{I,U}64`. This can cause unaligned memory accesses and data race. Crates using `fetch_*` methods with `AtomicCell<{i,u}64>` are affected by this issue. 32-bit targets without `Atomic{I,U}64` and 64-bit targets are not affected by this issue. This has been fixed in crossbeam-utils 0.8.7. There are currently no known workarounds.
Attacker Value
Unknown

CVE-2021-32810

Disclosure Date: August 02, 2021 (last updated February 23, 2025)
crossbeam-deque is a package of work-stealing deques for building task schedulers when programming in Rust. In versions prior to 0.7.4 and 0.8.0, the result of the race condition is that one or more tasks in the worker queue can be popped twice instead of other tasks that are forgotten and never popped. If tasks are allocated on the heap, this can cause double free and a memory leak. If not, this still can cause a logical bug. Crates using `Stealer::steal`, `Stealer::steal_batch`, or `Stealer::steal_batch_and_pop` are affected by this issue. This has been fixed in crossbeam-deque 0.8.1 and 0.7.4.
Attacker Value
Unknown

CVE-2020-35904

Disclosure Date: December 31, 2020 (last updated November 28, 2024)
An issue was discovered in the crossbeam-channel crate before 0.4.4 for Rust. It has incorrect expectations about the relationship between the memory allocation and how many iterator elements there are.
Attacker Value
Unknown

CVE-2020-15254

Disclosure Date: October 16, 2020 (last updated February 22, 2025)
Crossbeam is a set of tools for concurrent programming. In crossbeam-channel before version 0.4.4, 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. This has been fixed in crossbeam-channel 0.4.4.
Attacker Value
Unknown

CVE-2018-20996

Disclosure Date: August 26, 2019 (last updated November 27, 2024)
An issue was discovered in the crossbeam crate before 0.4.1 for Rust. There is a double free because of destructor mishandling.
0