PT-2020-17637

Name of the Vulnerable Software and Affected Versions toolshed crate through 2020-11-15 for Rust Description The issue concerns the CopyCell type in the toolshed crate, which lacks bounds on the contained type for the Send trait. This means that even though not all Copyable types are thread-safe,...

PT-2020-17650

Name of the Vulnerable Software and Affected Versions appendix crate through 2020-11-15 Description The issue concerns the implementation of the Index data structure in the appendix crate, which allows any type to inhabit the generic K and V type parameters and implements Send and Sync for them...

PT-2020-17626

Name of the Vulnerable Software and Affected Versions signal-simple crate versions through 2020-11-15 Description An issue was discovered in the signal-simple crate where there are unconditional implementations of Send and Sync for SyncChannel. This allows users to create undefined behavior in sa...

Send/Sync bound needed on T for Send/Sync impl of RcuCell<T>

Affected versions of this crate unconditionally implement Send/Sync for RcuCell. This allows users to send T: !Send to other threads while T enclosed within RcuCell, and allows users to concurrently access T: !Sync by using the APIs of RcuCell that provide access to &T. This can result in memory...

RUSTSEC-2020-0131 Send/Sync bound needed on T for Send/Sync impl of RcuCell<T>

Affected versions of this crate unconditionally implement Send/Sync for RcuCell. This allows users to send T: !Send to other threads while T enclosed within RcuCell, and allows users to concurrently access T: !Sync by using the APIs of RcuCell that provide access to &T. This can result in memory...

PT-2020-17632

Name of the Vulnerable Software and Affected Versions rcu cell crate through 2020-11-14 Description The issue allows users to send T: !Send to other threads while T is enclosed within RcuCell, and allows users to concurrently access T: !Sync by using the APIs of RcuCell that provide access to &T...

PT-2020-17635

Name of the Vulnerable Software and Affected Versions parc crate through 2020-11-14 Description An issue in the parc crate allows concurrent access to a non-Sync T, which can cause undefined behavior like data races. This is due to LockWeak unconditionally implementing Send without trait bounds o...

RUSTSEC-2020-0130 Bunch<T> unconditionally implements Send/Sync

Affected versions of this crate unconditionally implements Send/Sync for Bunch. This allows users to insert T: !Sync to Bunch. It is possible to create a data race to a T: !Sync by invoking the Bunch::get API which returns &T from multiple threads. It is also possible to send T: !Send to other...

AtomicBox<T> implements Send/Sync for any `T: Sized`

Affected versions of this crate implements Send/Sync for AtomicBox without requiring T: Send/T: Sync. This allows to create data races to T: !Sync and send T: !Send to another thread. Such behavior breaks the compile-time thread safety guarantees of Rust, and allows users to incur undefined...

AtomicBox<T> lacks bound on its Send and Sync traits allowing data races

AtomicBox is a Box type designed to be used across threads, however, it implements the Send and Sync traits for all types T. This allows non-Send types such as Rc and non-Sync types such as Cell to be used across thread boundaries which can trigger undefined behavior and memory corruption...

RUSTSEC-2020-0137 AtomicBox<T> lacks bound on its Send and Sync traits allowing data races

AtomicBox is a Box type designed to be used across threads, however, it implements the Send and Sync traits for all types T. This allows non-Send types such as Rc and non-Sync types such as Cell to be used across thread boundaries which can trigger undefined behavior and memory corruption...

PT-2020-17621

Name of the Vulnerable Software and Affected Versions abox crate versions prior to 0.4.1 Description An issue in the abox crate allows the implementation of Send and Sync for AtomicBox without requiring T: Send and T: Sync. This enables the creation of data races to T: !Sync and sending T: !Send ...

PT-2020-17639

Name of the Vulnerable Software and Affected Versions lexer crate through 2020-11-10 Description The issue is related to the implementation of Sync for ReaderResult with a trait bound of T: Send, E: Send, which can lead to data races and memory corruption when multiple threads access &T or &E...

Some lock_api lock guard objects can cause data races

Affected versions of lockapi had unsound implementations of the Send or Sync traits for some guard objects, namely: MappedMutexGuard MappedRwLockReadGuard MappedRwLockWriteGuard RwLockReadGuard RwLockWriteGuard These guards could allow data races through types that are not safe to Send across...

RUSTSEC-2020-0070 Some lock_api lock guard objects can cause data races

Affected versions of lockapi had unsound implementations of the Send or Sync traits for some guard objects, namely: MappedMutexGuard MappedRwLockReadGuard MappedRwLockWriteGuard RwLockReadGuard RwLockWriteGuard These guards could allow data races through types that are not safe to Send across...

WS-2020-0189

Affected versions of futures-rs had a Send/Sync implementation for MappedMutexGuard that only considered variance on T, while MappedMutexGuard dereferenced to U. This could of led to data races in safe Rust code when a closure used in MutexGuard::map returns U that is unrelated to T. The issue wa...

AtomicOption should have Send + Sync bound on its type argument.

In the affected versions of this crate, AtomicOption unconditionally implements Sync. This allows programmers to move non-Sync types across thread boundaries e.g. Rc, Arc, which can lead to data races and undefined behavior. It is also possible to send non-Send types like std::sync::MutexGuard to...

GenericMutexGuard allows data races of non-Sync types across threads

GenericMutexGuard was given the Sync auto trait as long as T is Send due to its contained members. However, since the guard is supposed to represent an acquired lock and allows concurrent access to the underlying data from different threads, it should only be Sync when the underlying data is. Thi...

RUSTSEC-2020-0113 AtomicOption should have Send + Sync bound on its type argument.

In the affected versions of this crate, AtomicOption unconditionally implements Sync. This allows programmers to move non-Sync types across thread boundaries e.g. Rc, Arc, which can lead to data races and undefined behavior. It is also possible to send non-Send types like std::sync::MutexGuard to...

RUSTSEC-2020-0072 GenericMutexGuard allows data races of non-Sync types across threads

GenericMutexGuard was given the Sync auto trait as long as T is Send due to its contained members. However, since the guard is supposed to represent an acquired lock and allows concurrent access to the underlying data from different threads, it should only be Sync when the underlying data is. Thi...