CVE-2017-20004

In the standard library in Rust before 1.19.0, there is a synchronization problem in the MutexGuard object. MutexGuards can be used across threads with any types, allowing for memory safety issues through race conditions...

CVE-2020-35905

An issue was discovered in the futures-util crate before 0.3.7 for Rust. MutexGuard::map can cause a data race for certain closure situations in safe code...

Design/Logic Flaw

An issue was discovered in the futures-util crate before 0.3.7 for Rust. MutexGuard::map can cause a data race for certain closure situations in safe code...

CVE-2020-35905

The CVE-2020-35905 issue affects the futures-util crate for Rust (pre-0.3.7). A MutexGuard::map path can cause a data race in safe code under certain closure scenarios. This is a local issue in the crate’s synchronization logic that could lead to data races, as described in the advisory and Red H...

CVE-2020-35905

An issue was discovered in the futures-util crate before 0.3.7 for Rust. MutexGuard::map can cause a data race for certain closure situations in safe code...

RUSTSEC-2020-0101 conquer-once's OnceCell lacks Send bound for its Sync trait.

Affected versions of conquer-once implements Sync for its OnceCell type without restricting it to Sendable types. This allows non-Send but Sync types such as MutexGuard to be sent across threads leading to undefined behavior and memory corruption in concurrent programs. The issue was fixed by...

ArcGuard's Send and Sync should have bounds on RC

Affected versions of this crate implement Send/Sync for ArcGuard with no trait bounds on RC. This allows users to send RC: !Send to other threads and also allows users to concurrently access Rc: !Sync from multiple threads. This can result in memory corruption from data race or other undefined...

SyncChannel<T> can move 'T: !Send' to other threads

Affected versions of this crate unconditionally implement Send/Sync for SyncChannel. SyncChannel doesn't provide access to &T but merely serves as a channel that consumes and returns owned T. Users can create UB in safe Rust by sending T: !Send to other threads with SyncChannel::send/recv APIs...

RUSTSEC-2020-0120 `Decoder<R>` can carry `R: !Send` to other threads

Affected versions of this crate implements Send for Decoder for any R: Read. This allows Decoder to contain R: !Send and carry move it to another thread. This can result in undefined behavior such as memory corruption from data race on R, or dropping R = MutexGuard from a thread that didn't lock...

`Decoder<R>` can carry `R: !Send` to other threads

Affected versions of this crate implements Send for Decoder for any R: Read. This allows Decoder to contain R: !Send and carry move it to another thread. This can result in undefined behavior such as memory corruption from data race on R, or dropping R = MutexGuard from a thread that didn't lock...

RUSTSEC-2020-0059 MutexGuard::map can cause a data race in safe code

Affected versions of the crate 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 was...

MutexGuard::map can cause a data race in safe code

Affected versions of the crate 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 was...