OMGeeky/advisory-db
1
0
Fork 0
mirror of https://github.com/OMGeeky/advisory-db.git synced 2025-12-29 15:56:07 +01:00
Code Issues Packages Projects Releases Wiki Activity

Merge pull request #731 from JOE1994/0060-noise_search

Browse Source 
noise_search: `MvccRwLock` allows data races & aliasing violations
This commit is contained in:
Sergey "Shnatsel" Davidoff
2021-02-01 14:58:19 +01:00
committed by GitHub
parent a2b63f4b82 7ef8c3d234
commit e9012b0ead
1 changed files with 18 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files

18
crates/noise_search/RUSTSEC-0000-0000.md Normal file
View File

@@ -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 types that are either `!Send` or `!Sync` (e.g. `Rc<T>`, `Arc<Cell<_>>`) 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<MutexGuard<Box<T>>>` 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).