Can access invalid memory and cause sigsegv using safe Rust

[ruuda]

When working on a crate I discovered the following issue. I did not succeed in making a minimal example that reproduces on play.rust-lang.org, so let me just link to the actual code:

• git clone -b rust-bug https://github.com/ruud-v-a/rx
• cd rx
• cargo test this_causes_sigsegv -- --nocapture
• This is the code that exploits the bug.
• There are no unsafe blocks in the crate.

Note how this prints the contents of some memory that the function shouldn’t be able to access, and then terminates with sigsegv.

An observation: with reexports it is possible to reexport a type on which a method is defined that returns a type that is not reexported. In a sense this allows returning anonymous types. In the documentation these types are named but they do not link to a documentation page, and if you name them explicitly the compiler complains because they are not public. I am not sure whether this is a bug or feature.

Related (what initially made me suspicious): this function mutates a variable that was borrowed mutably by a closure.

[ruuda]

Oh, and rustc version: rustc 1.8.0-nightly (75271d8f1 2016-02-09). I updated to rustc 1.8.0-nightly (c8fc4817d 2016-02-22) and the issue is still present.

[alexcrichton]

After reducing this, it looks like the bug is that the compiler accepts this:

trait Foo {                          
    fn foo<T>(&self, t: T);          
}                                    

impl Foo for i32 {                   
    fn foo<T: 'static>(&self, t: T) {
    }                                
}                                    

fn foo(a: i32, not_static: &i32) {   
    a.foo(not_static);               
}                                    

The i32 implementation is allowed to assume it's only given 'static content, when in fact we can feed in anything!

[alexcrichton]

In your code specifically @ruud-v-a the Observable::subscribe method requires just an O parameter whereas SubjectObservable::subscribe adds on 'static

[alexcrichton]

triage: I-nominated

This seems familiar as in we've had it reported before, but... I thought we fixed it with a bunch of well-formededness RFCs? Seems good to get visibility though!

cc @rust-lang/compiler

[alexcrichton]

Aha! and @nikomatsakis pointed out on IRC that this is #18937, so I'll just close in favor of that. Thanks for the report though @ruud-v-a!