Queues allow non-Send types to be sent to other threads, allowing data races

Affected versions of this crate unconditionally implemented Send for types used in queue implementations InnerSend, InnerRecv, FutInnerSend, FutInnerRecv. This allows users to send non-Send types to other threads, which can lead to data race bugs or other undefined behavior. The flaw was correcte...

RUSTSEC-2020-0152 ImmediateIO and TransactionalIO can cause data races

The ImmediateIO and TransactionalIO types implement Sync for all contained Expander types regardless of if the Expander itself is safe to use across threads. As the IO types allow retrieving the Expander, this can lead to non-thread safe types being sent across threads as part of the Expander...

RUSTSEC-2020-0098 UsbContext trait did not require implementers to be Send and Sync.

Affected versions of rusb did not require UsbContext to implement Send and Sync. However, through Device and DeviceHandle it is possible to use UsbContexts across threads. This issue allows non-thread safe UsbContext types to be used concurrently leading to data races and memory corruption. The...

ImmediateIO and TransactionalIO can cause data races

The ImmediateIO and TransactionalIO types implement Sync for all contained Expander types regardless of if the Expander itself is safe to use across threads. As the IO types allow retrieving the Expander, this can lead to non-thread safe types being sent across threads as part of the Expander...

SyncRef's clone() and debug() allow data races

Affected versions of this crate unconditionally implement Sync for SyncRef. This definition allows data races if &T is accessible through &SyncRef. SyncRef derives Clone and Debug, and the default implementations of those traits access &T by invoking T::clone & T::fmt. It is possible to create da...

RUSTSEC-2020-0127 SyncRef's clone() and debug() allow data races

Affected versions of this crate unconditionally implement Sync for SyncRef. This definition allows data races if &T is accessible through &SyncRef. SyncRef derives Clone and Debug, and the default implementations of those traits access &T by invoking T::clone & T::fmt. It is possible to create da...

RUSTSEC-2020-0129 ShmWriter allows sending non-Send type across threads

Affected versions of this crate implement Send for ShmWriter without requiring H: Send. This allows users to send H: !Send to other threads, which can potentially lead to data races and undefined behavior...

ShmWriter allows sending non-Send type across threads

Affected versions of this crate implement Send for ShmWriter without requiring H: Send. This allows users to send H: !Send to other threads, which can potentially lead to data races and undefined behavior...

UsbContext trait did not require implementers to be Send and Sync.

Affected versions of rusb did not require UsbContext to implement Send and Sync. However, through Device and DeviceHandle it is possible to use UsbContexts across threads. This issue allows non-thread safe UsbContext types to be used concurrently leading to data races and memory corruption. The...

RUSTSEC-2020-0150 RingBuffer can create multiple mutable references and cause data races

The RingBuffer type retrieves mutable references from the DataProvider in a non-atomic manner, potentially allowing the creation of multiple mutable references. RingBuffer also implements the Send and Sync traits for all types T. This allows undefined behavior from the aliased mutable references ...

RingBuffer can create multiple mutable references and cause data races

The RingBuffer type retrieves mutable references from the DataProvider in a non-atomic manner, potentially allowing the creation of multiple mutable references. RingBuffer also implements the Send and Sync traits for all types T. This allows undefined behavior from the aliased mutable references ...

RUSTSEC-2020-0148 Multiple soundness issues in `Ptr`

Affected versions of this crate have the following issues: 1. Ptr implements Send and Sync for all types, this can lead to data races by sending non-thread safe types across threads. 2. Ptr::get violates mutable alias rules by returning multiple mutable references to the same object. 3. Ptr::writ...

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

aovec::Aovec is a vector type that implements Send and Sync 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...

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

aovec::Aovec is a vector type that implements Send and Sync 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...

MvccRwLock allows data races & aliasing violations

Affected versions of this crate unconditionally implement Send/Sync for MvccRwLock. This can lead to data races when types that are either !Send or !Sync e.g. Rc, Arc are contained inside MvccRwLock and sent across thread boundaries. The data races can potentially lead to memory corruption as...

RUSTSEC-2020-0141 MvccRwLock allows data races & aliasing violations

Affected versions of this crate unconditionally implement Send/Sync for MvccRwLock. This can lead to data races when types that are either !Send or !Sync e.g. Rc, Arc are contained inside MvccRwLock and sent across thread boundaries. The data races can potentially lead to memory corruption as...

Multiple soundness issues in `Ptr`

Affected versions of this crate have the following issues: 1. Ptr implements Send and Sync for all types, this can lead to data races by sending non-thread safe types across threads. 2. Ptr::get violates mutable alias rules by returning multiple mutable references to the same object. 3. Ptr::writ...

RUSTSEC-2020-0139 dces' World type can cause data races

The World type in dces is marked as Send without bounds on its EntityStore and ComponentStore. This allows non-thread safe EntityStore and ComponentStores to be sent across threads and cause data races...

dces' World type can cause data races

The World type in dces is marked as Send without bounds on its EntityStore and ComponentStore. This allows non-thread safe EntityStore and ComponentStores to be sent across threads and cause data races...

Thex<T> allows data races of non-Send types across threads

thex::Thex implements Sync for all types T. However, it is missing a bound for T: Send. This allows non-Send types such as Rc to be sent across thread boundaries which can trigger undefined behavior and memory corruption...