Ability to take an Immutable reference to data that is mutated later through Obfuscation

[strega-nil]

If you pass an immutable reference through two structs, one of which is a trait, you can take an immutable reference to a variable that will be mutated later, and the compiler will compile. For a proof of concept, see here, and if you want to see it in an actual use case, see here (look in the main file).

I don't know if this is an issue or not, it didn't cause any safety issues when I used it. Is there a rust-ier way of doing the type of thing I did in the second example (allow an immutable reference to a value that will be mutated, in order to see the new value).

[huonw]

The whole thing in one piece:

pub struct Referrable {
    x: i64
}

impl Referrable {
    pub fn new() -> Referrable {
        Referrable { x: 0i64 }
    }

    pub fn update(&mut self) {
        self.x += 1;
    }
}

pub trait Segger<'a> {
    fn new(&'a Referrable) -> Self;
    fn update(& self);
}

pub struct SegFault<'a> {
    r: &'a Referrable
}

impl<'a> Segger<'a> for SegFault<'a> {
    fn new(r: &'a Referrable) -> SegFault<'a> {
        SegFault { r: r }
    }

    fn update(& self) {
        println!("{}", self.r.x);
    }
}


pub struct SegObscure<'a> {
    seg: Box<Segger<'a> + 'a>
}

impl<'a> SegObscure<'a> {
    pub fn new(r: & Referrable) -> SegObscure<'a> {
        let seg: Box<SegFault> = box Segger::new(r);
        SegObscure { seg: seg }
    }

    pub fn update(& self) {
        self.seg.update();
    }
}

fn main() {
    let mut r = Referrable::new();
    let s = SegObscure::new(& r);
    for _ in range(0i, 10i) {
        s.update();
        r.update();
    }
    r = Referrable::new();
    s.update();
    // Still works!
}

Thanks for filing, these memory safety bugs are very important to catch, however, I think this may be a duplicate of another bug which I cannot find right now (iirc @zwarich was interacting with those other bugs). I believe the underlying problem here is the function pub fn new(r: & Referrable) -> SegObscure<'a> { is invalid, the boxing/returning that happens should be disallowed without the r having the 'a lifetime too.

[ftxqxd]

FWIW, I’ve reduced the issue a little more (playpen):

trait Segger<'a> {
    fn new(&'a int) -> Self;
    fn get(&self) -> int;
}

struct SegFault<'a> {
    r: &'a int,
}

impl<'a> Segger<'a> for SegFault<'a> {
    fn new(r: &'a int) -> SegFault<'a> { SegFault { r: r } }
    fn get(&self) -> int { *self.r }
}

struct SegObscure<'a> {
    seg: Box<Segger<'a> + 'a>,
}

impl<'a> SegObscure<'a> {
    fn new(r: &'a int) -> SegObscure<'a> {
        //     ^
        // Interestingly, this lifetime can be removed with no effect
        let seg: Box<SegFault> = box Segger::new(r);
        SegObscure { seg: seg }
    }
}

fn main() {
    let mut r = vec![42i];
    let s = SegObscure::new(&r[0]);
    println!("{}", s.seg.get());

    // We can do all sorts of evil things
    r.pop();
    drop(r);

    // We can now (rather unreliably) overwrite what was in r[0] previously by
    // allocating something somewhere in memory
    let _ = box 36i;

    // ...and we've changed the value magically
    println!("{}", s.seg.get());
}

[alexcrichton]

Nominating

[arielb1]

As I posted on IRC, this is a variance problem - SegObscure<'a> is unsoundly bivariant:

pub trait Segger {
    fn val(& self) -> uint;
}

impl<'a> Segger for &'a uint {
    fn val(& self) -> uint{
        **self
    }
}

pub struct SegObscure<'a> {
    seg: Box<Segger + 'a>
}

// This function is sound
fn create<'a>(r: &'a uint) -> SegObscure<'a> {
        let seg: Box<&'a uint> = box r;
        SegObscure { seg: seg }
}

// WRONG!
fn create_dangling_pointer() -> SegObscure<'static> {
    let r = 1u;
    create(&r)
}

fn access(s: SegObscure) {
  println!("{}", s.seg.val());
}

fn main() {
    let s = create_dangling_pointer();
    access(s);
}

[strega-nil]

Thanks for cutting it down. I still am not a good Rust programmer, so I was just copying, as close as I could, the original, accidental, version.

[alexcrichton]

cc @nikomatsakis

[pnkfelix]

P-backcompat-lang, 1.0.

[nikomatsakis]

seems to be dup of #18262

[nikomatsakis]

I tested and this is indeed fixed by PR #18371. Too bad I didn't look into this bug first rather than #18262, since I see that other people already worked out the variance connection already.