Rust equivalent for C++ code to demonstrate protection against UAF - rust

Question

I am trying to understand how Rust's lifetime annotations help catch use-after-free (UAF) issues without compromising on functionality. Here is the code I have :
use std::rc::Rc;
struct Foo {
data: usize,
}
impl Foo {
pub fn begin_foo(&self) {
println!("Begin Foo");
}
pub fn end_foo(&self) {
println!("End Foo");
}
}
struct Bar {
foo: Option<Foo>,
}
impl Bar {
pub fn new(foo: Foo) -> Self {
Bar {
foo : Some(foo),
}
}
pub fn get_foo(&self) -> Option<& Foo>
{
match &self.foo {
Some(foo) => return Some(&foo),
None => return None,
}
}
}
struct FooBar<'a> {
bar : Option<Rc<Bar>>,
foo : Option<&'a Foo>,
}
impl<'a> FooBar<'a> {
pub fn new(bar : Option<Rc<Bar>>) -> Self {
FooBar {
bar : bar,
foo : None,
}
}
pub fn update_foo_1(&'a mut self)
{
if let Some(b) = &self.bar {
self.foo = b.get_foo();
}
}
// ERROR1
/*
pub fn update_foo_2(&mut self)
{
if let Some(b) = &self.bar {
self.foo = b.get_foo();
}
}
*/
pub fn invalidate_bar_1(&mut self) {
self.bar.take();
}
// Inorder to drop the RC, we have to pass self and not &self, which consumes the object.
pub fn invalidate_bar_2(self) {
if let Some(bar) = &self.bar {
println!("Strong ref count = {}", Rc::strong_count(bar));
drop(self.bar.unwrap());
}
}
pub fn use_foo(&self) {
match self.foo {
Some(foo) => println!("Foo.data = {}", foo.data),
None => println!("Foo is None"),
}
}
}
#[cfg(test)]
mod tests {
use super::*;
#[test]
fn works()
{
println!("Works...");
let foo = Foo {data : 42};
let bar = Bar::new(foo);
let bar_rc = Rc::new(bar);
assert_eq!(1, Rc::strong_count(&bar_rc));
let mut foo_bar: FooBar = FooBar::new(Some(bar_rc));
foo_bar.update_foo_1();
foo_bar.use_foo();
foo_bar.invalidate_bar_1();
println!("Exiting works()...");
}
#[test]
fn fails()
{
println!("Fails...");
let foo = Foo {data : 42};
let bar = Bar::new(foo);
let bar_rc = Rc::new(bar);
assert_eq!(1, Rc::strong_count(&bar_rc));
let mut foo_bar: FooBar = FooBar::new(Some(bar_rc));
foo_bar.update_foo_1();
foo_bar.invalidate_bar_1();
foo_bar.use_foo();
println!("Exiting fails()...");
}
}
The requirement is that FooBar holds Bar but also a reference to Foo to avoid calling Bar::get_foo() multiple times. FooBar::invalidate_bar_*() invalidates Bar leaving the reference Foo dangling.
Given the above requirement, the following sequence of calls should be valid :
foobar.update_foo();
foobar.use_foo();
foobar.invalidate_foo();
The following is an invalid sequence of calls and must be caught at compile-time :
foobar.update_foo();
foobar.invalidate_foo();
foobar.use_foo();
But this doesn't quite happen with my code above. The challenges that I am facing are:
In FooBar::update_foo_1() I am forced to annotate self with lifetime &'a. Otherwise I get the following error :
error[E0495]: cannot infer an appropriate lifetime for borrow expression due to conflicting requirements
--> src/lib.rs:52:26
|
52 | if let Some(b) = &self.bar {
| ^^^^^^^^^
|
note: first, the lifetime cannot outlive the anonymous lifetime #1 defined on the method body at 50:5...
--> src/lib.rs:50:5
|
50 | / pub fn update_foo_1(& mut self)
51 | | {
52 | | if let Some(b) = &self.bar {
53 | | self.foo = b.get_foo();
54 | | }
55 | | }
| |_____^
note: ...so that reference does not outlive borrowed content
--> src/lib.rs:52:26
|
52 | if let Some(b) = &self.bar {
| ^^^^^^^^^
note: but, the lifetime must be valid for the lifetime `'a` as defined on the impl at 42:6...
--> src/lib.rs:42:6
|
42 | impl<'a> FooBar<'a> {
| ^^
note: ...so that the expression is assignable
--> src/lib.rs:53:24
|
53 | self.foo = b.get_foo();
| ^^^^^^^^^^^
= note: expected `std::option::Option<&'a Foo>`
found `std::option::Option<&Foo>`
When I use the &'a to resolve the above error, I cannot make any other calls that require exclusive reference to self in the same scope :
error[E0502]: cannot borrow `foo_bar` as immutable because it is also borrowed as mutable
--> src/lib.rs:104:9
|
103 | foo_bar.update_foo_1();
| ------- mutable borrow occurs here
104 | foo_bar.use_foo();
| ^^^^^^^
| |
| immutable borrow occurs here
| mutable borrow later used here

Answer 1

By calling this, you are making FooBar a self referential struct which is hard to define in safe rust.
pub fn update_foo_1(&'a mut self)
{
if let Some(b) = &self.bar {
self.foo = b.get_foo();
}
}
The compiler gives the error correctly here:
error[E0502]: cannot borrow `foo_bar` as immutable because it is also borrowed as mutable
--> src/lib.rs:104:9
|
103 | foo_bar.update_foo_1();
| ------- mutable borrow occurs here
104 | foo_bar.use_foo();
| ^^^^^^^
| |
| immutable borrow occurs here
| mutable borrow later used here
because if it did allow any immutable borrows after the update call, it would mean that there is no mutable borrow at that point, which also means that you can do mutable borrows after that.
What happens if the bar field's strong count was 1 and you did this:
drop(foo_bar.bar.take());
You'd have a dangling reference in the foo field of FooBar, which Rust forbids.

Answer 2

Rust's lifetime annotations help catch use-after-free (UAF) issues without compromising on functionality.
Rust's lifetime annotations don't "catch" anything. What they do is tell the compiler about things it may not be able to infer (namely how long borrows span).
What "catches" UAF issues is the affine type system, that is, after a move (aka taking something by value unless it's Copy), the source is inaccessible, and you can't move a structure which are active users (aka for which there are active references, all borrows must end before a structure is moved).
You're not using moves anywhere, so your FooBar object is guaranteed to always be valid.
As for the update_foo_1 issue, I think it's a logical consequence of what you're telling rust:
pub fn update_foo_1(&'a mut self)
means that method is creating a borrow which lasts all of 'a.
'a is a parameter to the structure so it needs to "outlive" the structure itself, and you're saying that you're exclusively borrowing the structure for that lifetime, which means 'a is exactly the same lifetime as the structure (which makes sense since what you're borrowing is part of the structure) and the only thing you've done is statically locked yourself out of using said structure.
Expressing graphs (/ self-referential structures) is difficult to do in Rust, and that's exactly what you're trying to do here, but more fundamentally your entire endeavour seems misguided and based on misunderstandings.