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

References

• pipedown/noise#72
• https://rustsec.org/advisories/RUSTSEC-2020-0141.html