Most recent entries from all

EUVD-2026-47901

2026-10-04T17:05:35.640677+00:00

EUVD-2026-47901

fkie_cve-2020-35905

2026-10-04T17:05:35.640710+00:00

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

GHSA-rh4w-94hh-9943 — MutexGuard::map can cause a data race in safe code

2026-10-04T17:05:35.640739+00:00

Affected: crates.io: futures-util

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 fixed by fixing Send and Sync implementations, and by adding a PhantomData<&'a mut U> marker to the MappedMutexGuard type to tell the compiler that the guard is over U too.

gsd-2020-35905

2026-10-04T17:05:35.640768+00:00

gsd-2020-35905

openSUSE-SU-2024:11751-1 — afterburn-5.0.0-6.1 on GA media

2026-10-04T17:05:35.640780+00:00

afterburn-5.0.0-6.1 on GA media

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

2026-10-04T17:05:35.640798+00:00

Affected: crates.io: futures-util

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 fixed by fixing `Send` and `Sync` implementations, and by adding a `PhantomData<&'a mut U>` marker to the `MappedMutexGuard` type to tell the compiler that the guard is over U too.