I wonder if this sort of vulnerability is possible in Rust, and if it is, is there a way to use Rust's borrow checker to make it impossible?
> I wonder if this sort of vulnerability is possible in Rust
Rusts borrow checker is designed for the more general case of "use-after-invalidation" and `free` is treated as a simple invalidation of what happens to be a heap allocated structure.
Interestingly, the borrow checker also prevents invalidations that are still common in memory-safe languages such as iterator invalidation.
pub trait Decode : Sized {
fn decode<D: Decoder>(decoder: D) -> Result<(Self, D::Done), D::Error>;
}
The trick here is that the decode() method consumes the decoder, and then returns it in the output. In the case of decoding an IO stream, the D::Done type is the IO stream itself, which means that in the event of an error, we ensure that the user can't accidentally use the IO stream again in an incompletely decoded state because all they have is the error type, D::Error (they can intentionally use the IO stream again by recovering the IO stream handle from the D::Error type).
In practice, the above results in decode() implementations that look like the following:
fn decode<D: Decoder>(decoder: D) -> Result<(Foo, D::Done), D::Error> {
let (v0, decoder) = decoder.decode()?;
let (v1, decoder) = decoder.decode()?;
let (v2, decoder) = decoder.decode()?;
Ok((Foo(v0, v1, v2),
decoder.done()?))
}
A common case where I see people trying to do this is when you have a struct where you are trying to replace a member variable:
struct Foo {
thing: Vec<i32>,
}
impl Foo {
fn something(&mut self) -> Vec<i32> {
let temp = self.thing;
// If we panicked between these two lines, then the struct would be in an undefined state
self.thing = vec![1];
temp
}
}
use std::mem;
impl Foo {
fn something(&mut self) -> Vec<i32> {
mem::replace(&mut self.thing, vec![1])
}
} struct Foo { bar: Bar }
struct Bar { message: &'static str }
fn change_foo(foo: &mut Foo) {
change_bar(&mut foo.bar);
}
fn change_bar(bar: &mut Bar) {
bar.message = "Invalid";
if true {
panic!();
}
bar.message = "Valid";
}
impl Drop for Foo {
fn drop(&mut self) {
println!("{}", self.bar.message);
}
}
fn main() {
let mut foo = Foo { bar: Bar { message: "" } };
change_foo(&mut foo);
}
For what it's worth, the solution I've seen for this type of case is another struct that is used to restore to an acceptable state:
fn change_bar(bar: &mut Bar) {
let mut restore = Restore(bar);
restore.message = "Invalid";
if true {
panic!();
}
restore.message = "Valid";
// Don't rollback on success
std::mem::forget(restore);
}
struct Restore<'a>(&'a mut Bar);
// Put back to an acceptable state
impl<'a> Drop for Restore<'a> {
fn drop(&mut self) {
self.0.message = "Restored to some state";
}
}
// Sugar so we don't have to know about the wrapper
impl<'a> std::ops::Deref for Restore<'a> {
type Target = Bar;
fn deref(&self) -> &Bar { self.0 }
}
// Sugar so we don't have to know about the wrapper
impl<'a> std::ops::DerefMut for Restore<'a> {
fn deref_mut(&mut self) -> &mut Bar { self.0 }
}This is a general problem with cross-language data access. The languages may not have the same data model. It's especially bad when one side has garbage collection, and the other side has to have explicit GC-aware code.