Skip to content

Commit

Permalink
Assigned RUSTSEC-2020-0059 to futures-util (#456)
Browse files Browse the repository at this point in the history
Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com>
  • Loading branch information
github-actions[bot] authored Oct 30, 2020
1 parent a36b118 commit 9cd2504
Showing 1 changed file with 24 additions and 24 deletions.
Original file line number Diff line number Diff line change
@@ -1,24 +1,24 @@
```toml
[advisory]
id = "RUSTSEC-0000-0000"
package = "futures-util"
date = "2020-10-22"
url = "https://github.com/rust-lang/futures-rs/issues/2239"
categories = ["memory-corruption"]
keywords = ["concurrency", "memory-corruption", "memory-management"]

[affected]
functions = { "futures_util::lock::MutexGuard::map" = [">= 0.3.2"] }

[versions]
patched = [">= 0.3.7"]
unaffected = ["< 0.3.2"]
```

# 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 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.
```toml
[advisory]
id = "RUSTSEC-2020-0059"
package = "futures-util"
date = "2020-10-22"
url = "https://github.com/rust-lang/futures-rs/issues/2239"
categories = ["memory-corruption"]
keywords = ["concurrency", "memory-corruption", "memory-management"]

[affected]
functions = { "futures_util::lock::MutexGuard::map" = [">= 0.3.2"] }

[versions]
patched = [">= 0.3.7"]
unaffected = ["< 0.3.2"]
```

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

0 comments on commit 9cd2504

Please sign in to comment.