RGB-Tools / RGB-Tools/rust-lightning
RUSTSEC-2020-0070: Some lock_api lock guard objects can cause data races
Nobody has claimed this yet.
- Dominant language
- Rust
- Stars
- 9
- Forks
- 18
- PR merge metrics
- No merged PRs in 30d
Description
Some lock_api lock guard objects can cause data races
| Details | |
|---|---|
| Status | unsound |
| Package | lock_api |
| Version | 0.3.4 |
| URL | https://github.com/Amanieu/parking_lot/pull/262 |
| Date | 2020-11-08 |
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.
See advisory page for additional details.
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start by checking how this repository depends on lock_api 0.3.4, then read the linked upstream pull request and RustSec advisory for the affected guard types and fixed bounds. Done means the repository no longer uses the affected lock_api version and its dependency checks pass.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- rust
- Domain
- security
- Issue type
- Bug
- Difficulty
- 2/5
- Estimated time
- 1-3 hours
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 25/100