You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Right now there is no mechanism in Cell to track whether a mutable reference to the data is already acquired. Thus it is possible to obtain several mutable references to the same memory location by calling Cell::get_mut() repeatedly:
let mycell = Cell::new(vec![1,2,3]);let ref1 = mysell.get_mut();let ref2 = mysell.get_mut();// obtained a second mutable reference; UB starts here
This may result in pretty much arbitrary memory corruption, most likely a use-after-free. Even though no code internal to Actix makes two obvious calls to get_mut() in a row, this behavior has been shown to be exploitable from the public API (see PoC that fails MIRI).
PR #158 has removed one instance of this Cell and all uses of it. However, there is another copy of it in the repository in actix-utils crate, and there are 23 calls to .get_mut().
The obvious fix is to replace all uses of custom Cell<T> with Rc<RefCell<T>> (the way it was before the introduction of a custom cell in 20b03a4), like it was done in #158.
The text was updated successfully, but these errors were encountered:
Right now there is no mechanism in
Cell
to track whether a mutable reference to the data is already acquired. Thus it is possible to obtain several mutable references to the same memory location by callingCell::get_mut()
repeatedly:This may result in pretty much arbitrary memory corruption, most likely a use-after-free. Even though no code internal to Actix makes two obvious calls to
get_mut()
in a row, this behavior has been shown to be exploitable from the public API (see PoC that fails MIRI).PR #158 has removed one instance of this Cell and all uses of it. However, there is another copy of it in the repository in
actix-utils
crate, and there are 23 calls to.get_mut()
.The obvious fix is to replace all uses of custom
Cell<T>
withRc<RefCell<T>>
(the way it was before the introduction of a custom cell in 20b03a4), like it was done in #158.The text was updated successfully, but these errors were encountered: