Question 1

Is there a bug in lock_api 0.0.0-0?

Accepted Answer

Some lock_api lock guard objects can cause data races Affected versions of lock_api had unsound implementations of the `Send` or
`Sync` traits for some guard objects, namely:

* MappedMutexGuard
* MappedRwLockReadGuard
* MappedRwLockWriteGuard
* RwLockReadGuard
* RwLockWriteGuard

These guards could allow data races through types that are not safe to `Send`
across thread boundaries in safe Rust code.

This issue was fixed by changing the trait bounds on the `Mapped` guard types
and removing the `Sync` trait for the `RwLock` guards. Fixed in lock_api 0.4.2.

Question 2

Is there a bug in lock_api?

Accepted Answer

Data races in lock_api An issue was discovered in the lock_api crate before 0.4.2 for Rust. A data race can occur because of MappedRwLockReadGuard unsoundness. Fixed in lock_api 0.4.2.

Question 3

Is there a bug in lock_api?

Accepted Answer

Data races in lock_api An issue was discovered in the lock_api crate before 0.4.2 for Rust. A data race can occur because of MappedMutexGuard unsoundness. Fixed in lock_api 0.4.2.

Question 4

Is there a bug in lock_api?

Accepted Answer

Data races in lock_api An issue was discovered in the lock_api crate before 0.4.2 for Rust. A data race can occur because of RwLockReadGuard unsoundness. Fixed in lock_api 0.4.2.

Question 5

Is there a bug in lock_api?

Accepted Answer

Data races in lock_api An issue was discovered in the lock_api crate before 0.4.2 for Rust. A data race can occur because of RwLockWriteGuard unsoundness. Fixed in lock_api 0.4.2.

Question 6

Is there a bug in lock_api?

Accepted Answer

Data races in lock_api An issue was discovered in the lock_api crate before 0.4.2 for Rust. A data race can occur because of MappedRwLockWriteGuard unsoundness. Fixed in lock_api 0.4.2.

Severity	Affected	Fixed in	Title	Status	Source
medium	0.0.0-0	0.4.2	Some lock_api lock guard objects can cause data races Affected versions of lock_api had unsound implementations of the `Send` or `Sync` traits for some guard objects, namely: * MappedMutexGuard * MappedRwLockReadGuard * MappedRwLockWriteGuard * RwLockReadGuard * RwLockWriteGuard These guards could allow data races through types that are not safe to `Send` across thread boundaries in safe Rust code. This issue was fixed by changing the trait bounds on the `Mapped` guard types and removing the `Sync` trait for the `RwLock` guards.	fixed	osv:RUSTSEC-2020-0070
medium	any	0.4.2	Data races in lock_api An issue was discovered in the lock_api crate before 0.4.2 for Rust. A data race can occur because of MappedRwLockReadGuard unsoundness.	fixed	osv:GHSA-vh4p-6j7g-f4j9
medium	any	0.4.2	Data races in lock_api An issue was discovered in the lock_api crate before 0.4.2 for Rust. A data race can occur because of MappedMutexGuard unsoundness.	fixed	osv:GHSA-ppj3-7jw3-8vc4
medium	any	0.4.2	Data races in lock_api An issue was discovered in the lock_api crate before 0.4.2 for Rust. A data race can occur because of RwLockReadGuard unsoundness.	fixed	osv:GHSA-hj9h-wrgg-hgmx
medium	any	0.4.2	Data races in lock_api An issue was discovered in the lock_api crate before 0.4.2 for Rust. A data race can occur because of RwLockWriteGuard unsoundness.	fixed	osv:GHSA-gmv4-vmx3-x9f3
medium	any	0.4.2	Data races in lock_api An issue was discovered in the lock_api crate before 0.4.2 for Rust. A data race can occur because of MappedRwLockWriteGuard unsoundness.	fixed	osv:GHSA-5wg8-7c9q-794v

lock_api known bugs