Most recent entries from all

cnvd-2021-85288

EUVD-2026-48207

fkie_cve-2020-36461

An issue was discovered in the noise_search crate through 2020-12-10 for Rust. There are unconditional implementations of Send and Sync for MvccRwLock.

GHSA-wxjf-9f4g-3v44 — Data races in noise_search

Affected: crates.io: noise_search

Affected versions of the `noise_search` 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).

gsd-2020-36461

RUSTSEC-2020-0141 — MvccRwLock allows data races & aliasing violations

Affected: crates.io: noise_search

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