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.

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.

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.

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

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

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