From 313915b6c1102c16bb535abf34fc5323c265a852 Mon Sep 17 00:00:00 2001 From: JOE1994 Date: Sun, 31 Jan 2021 23:19:36 -0500 Subject: [PATCH 1/2] Report 0060-noise_search to RustSec --- crates/noise_search/RUSTSEC-0000-0000.md | 18 ++++++++++++++++++ 1 file changed, 18 insertions(+) create mode 100644 crates/noise_search/RUSTSEC-0000-0000.md diff --git a/crates/noise_search/RUSTSEC-0000-0000.md b/crates/noise_search/RUSTSEC-0000-0000.md new file mode 100644 index 0000000..bf5d0bd --- /dev/null +++ b/crates/noise_search/RUSTSEC-0000-0000.md @@ -0,0 +1,18 @@ +```toml +[advisory] +id = "RUSTSEC-0000-0000" +package = "noise_search" +date = "2020-12-10" +url = "https://github.com/pipedown/noise/issues/72" +categories = ["memory-corruption", "thread-safety"] + +[versions] +patched = [] +``` + +# MvccRwLock allows data races & aliasing violations + +Affected versions of this crate unconditionally implement Send/Sync for `MvccRwLock`. +This can lead to data races when non Send types like `Cell` or `Rc` are contained inside `MvccRwLock` and sent across thread boundaries. The data races can potentially lead to memory corruption (as demonstrated in the PoC from the original report issue). + +Also, safe APIs of `MvccRwLock` allow aliasing violations by allowing `&T` and `LockResult>>` to co-exist in conflicting lifetime regions. The APIs of `MvccRwLock` should either be marked as `unsafe` or `MbccRwLock` should be changed to private or pub(crate). \ No newline at end of file From 7ef8c3d2348658754bb98ab151636f3b5203088b Mon Sep 17 00:00:00 2001 From: Youngsuk Kim Date: Sun, 31 Jan 2021 23:24:23 -0500 Subject: [PATCH 2/2] Update advisory for 'noise_search' crate --- crates/noise_search/RUSTSEC-0000-0000.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/crates/noise_search/RUSTSEC-0000-0000.md b/crates/noise_search/RUSTSEC-0000-0000.md index bf5d0bd..df2fa1c 100644 --- a/crates/noise_search/RUSTSEC-0000-0000.md +++ b/crates/noise_search/RUSTSEC-0000-0000.md @@ -13,6 +13,6 @@ patched = [] # MvccRwLock allows data races & aliasing violations Affected versions of this crate unconditionally implement Send/Sync for `MvccRwLock`. -This can lead to data races when non Send types like `Cell` or `Rc` are contained inside `MvccRwLock` and sent across thread boundaries. The data races can potentially lead to memory corruption (as demonstrated in the PoC from the original report issue). +This can lead to data races when types that are either `!Send` or `!Sync` (e.g. `Rc`, `Arc>`) are contained inside `MvccRwLock` and sent across thread boundaries. The data races can potentially lead to memory corruption (as demonstrated in the PoC from the original report issue). -Also, safe APIs of `MvccRwLock` allow aliasing violations by allowing `&T` and `LockResult>>` to co-exist in conflicting lifetime regions. The APIs of `MvccRwLock` should either be marked as `unsafe` or `MbccRwLock` should be changed to private or pub(crate). \ No newline at end of file +Also, safe APIs of `MvccRwLock` allow aliasing violations by allowing `&T` and `LockResult>>` to co-exist in conflicting lifetime regions. The APIs of `MvccRwLock` should either be marked as `unsafe` or `MbccRwLock` should be changed to private or pub(crate).