-
Notifications
You must be signed in to change notification settings - Fork 354
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Assigned RUSTSEC-2020-0059 to futures-util (#456)
Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com>
- Loading branch information
1 parent
a36b118
commit 9cd2504
Showing
1 changed file
with
24 additions
and
24 deletions.
There are no files selected for viewing
48 changes: 24 additions & 24 deletions
48
crates/futures-util/RUSTSEC-0000-0000.md → crates/futures-util/RUSTSEC-2020-0059.md
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
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. |