CVE-2017-20004

CVE-2017-20004 affects the Rust standard library prior to 1.19.0, where a synchronization flaw in the MutexGuard object allows MutexGuards to be used across threads with arbitrary types, enabling memory-safety issues via data races. Affected component: Rust standard library; vulnerable version ra...

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

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...

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...

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...

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...