CVE-2020-35911

Vulnerability

The lock_api crate (up to version 0.4.1) contained an unsoundness in the MappedRwLockReadGuard type, which allowed a data race to occur. The issue stemmed from incorrect Send and Sync trait bounds on the guard's implementation. Under certain conditions, this could permit safe Rust code to trigger undefined behavior by sending the guard across threads where the underlying lock's data was not properly synchronized [1][2].

Exploitation

Exploitation requires a program using lock_api with MappedRwLockReadGuard in a multithreaded context. No special authentication is needed beyond being able to execute code that creates and transfers such guards between threads. An attacker controlling a thread could send a guard to another thread, breaking Rust's concurrency guarantees and potentially accessing the protected data without proper locking, leading to a data race [2][4].

Impact

An attacker or malicious code could cause a data race, which in Rust leads to undefined behavior. This could manifest as memory corruption, information leaks, or arbitrary code execution, depending on how the racing threads access shared memory [2][4]. The vulnerability is categorized as 'unsound' in the Rust security advisory, indicating that safe code can invoke undefined behavior.

Mitigation

The issue was fixed in lock_api version 0.4.2 by correcting the Send/Sync bounds on the guard type [1][2][4]. Users should update to 0.4.2 or later. The parking_lot crate, which commonly uses lock_api, may also need updating if it depends on the vulnerable version. The vulnerability is not listed on CISA's Known Exploited Vulnerabilities (KEV) catalog as of the advisory date [3].