-
Notifications
You must be signed in to change notification settings - Fork 31
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
MapGuard dereferences to a dangling pointer #45
Comments
Hello It's a great discovery, though disturbing this has slipped through. I'll have to think how to plug this problem in a way that doesn't disrupt users too much, but I'll have a look at it today or tomorrow. Thank you for finding it. |
The assumption that the address of access's guarded reference stays the same is not true. Costs: * The Map is now slower and adds an allocation. * It no longer can be Clone (but non-trivial guards weren't anyway) and it can stop being Sync/Send if the closure is not. Fixes #45. Technically, it is a breaking change, but the plan is not to raise major version, because: * Even rust std gives exception to break compatibility for soundness hole fixes. * It is not that likely people's code would break. * Even if it breaks, they are much more likely to go to the fixed version then if the version got bumped and that's what they should be doing ASAP due to the potential UB.
Fix released as 1.1.0 (by eliminating all unsafe code in that file). It is technically a breaking change, but the chance of actually breaking code is low and the chance people will migrate from the broken version are higher this way, and even rustc makes an exception for soundness issues in the stability guarantees. It seems less bad to release as part of the 1. version. |
Backport to the 0.4 version, releasing as 0.4.8. The assumption that the address of access's guarded reference stays the same is not true. Costs: * The Map is now slower and adds an allocation. * It can stop being Copy (but non-trivial guards weren't anyway) and it can stop being Sync/Send if the closure is not. * The taken closure needs to be Clone. Fixes #45. Technically, it is a breaking change, but the plan is not to raise major version, because: * Even rust std gives exception to break compatibility for soundness hole fixes. * It is not that likely people's code would break. * Even if it breaks, they are much more likely to go to the fixed version then if the version got bumped and that's what they should be doing ASAP due to the potential UB.
Added a backport, released as |
Thank you for the quick fix! |
CVE-2020-35711 was assigned to this issue. |
Hello fellow Rustacean,
we (Rust group @sslab-gatech) are scanning Rust code on crates.io for potential memory safety and soundness bugs and found an issue in this crate which allows safe Rust code to exhibit an undefined behavior.
Issue Description
arc-swap/src/access.rs
Lines 279 to 293 in b5ec44c
arc-swap/src/access.rs
Lines 230 to 242 in b5ec44c
As noted in the comment, unsafe code in
MapGuard
expects the underlying guard type to dereferences to the same value even when the guard object is moved. However,Map
usesAccess
as a trait bound which does not guarantee this property. As a result,Map
accesses a dangling pointer when it is used with anAccess
implementation that does not dereferences to the same value when moved.arc-swap/src/access.rs
Lines 295 to 322 in b5ec44c
Constant
seems to be the only type in this crate that implementsAccess
in this way, but there can be other user types that implementsAccess
on their own.Reproduction
Below is an example program that segfaults, written only with safe APIs of
arc-swap
.Show Detail
Output:
Tested Environment
The text was updated successfully, but these errors were encountered: