Incoherent (?) Lifetime HRTB on associated type results in unsoundness in stable, safe code

[maxdexh]

This code results in undefined behavior in safe code.

use std::any::Any;

// `for<'a> Producer<&'a T>` is equivalent to the (non-existent) `for<'a> FnOnce() -> &'a T`
pub trait Producer<T>: FnOnce() -> T {}
impl<T, F: FnOnce() -> T> Producer<T> for F {}

// What does `P::Output` even mean in this context? If this was `FnOnce(&()) -> &T`, using `Output`
// would result in "Cannot use the assiciated type of a trait with uninferred generic parameters",
// even when hiding behind an extra trait
fn write_incoherent_p2<T, P: for<'a> Producer<&'a T>>(
    weird: P::Output,
    out: &mut &'static dyn Any,
) {
    // `T` is not even `'static`, but `P::Output` seems to kind of 
    // resemble `for<'a> &'a T` (if that even means anything)
    *out = weird;
}

fn write_incoherent_p1<T, P: for<'a> Producer<&'a T>>(p: P, out: &mut &'static dyn Any) {
    // Producing and writing p() in one function doesn't work. Doing so requires T: 'static.
    // Adding T: 'static to all functions also makes this not work.
    // This fragility is why every line is its own function. 
    write_incoherent_p2::<T, P>(p(), out)
}

// Now we can trigger unsoundness by finding something that is `FnOnce() -> &'a T` for any `'a`
// `for<'a> FnOnce() -> &'a T` is basically just the signature of Box::leak
fn construct_implementor<T>(not_static: T, out: &mut &'static dyn Any) {
    write_incoherent_p1::<T, _>(|| Box::leak(Box::new(not_static)), out);
}

fn make_static_and_drop<T: 'static>(t: T) -> &'static T {
    let mut out: &'static dyn Any = &();
    construct_implementor::<&T>(&t, &mut out);
    *out.downcast_ref::<&T>().unwrap()
}

fn main() {
    println!("{:?}", make_static_and_drop(vec![vec![1]])); // use after free
}

The earliest affected version is 1.72 1.67.0. Many All earlier versions reject construct_implementor, but most just 1.70.0-1.72.0 ICE. Current nightly is also affected.

I am not entirely sure what is going on in this code; I was trying to create a function type that returns a reference of any requested lifetime (don't ask why), i.e. for<'a> Fn() -> &'a T. For some reason it works when hiding behind a blanket implementation, though it is very fragile. Taking Fn::Output of such a function type yields a type that seems to kind of resemble "for<'a> &'a T" and allows assignment to &'static dyn Any, even though T is not 'static.

[lcnr]

Fun ✨

trait WriteWhereClause<T>: FnOnce() -> T {}
impl<F: FnOnce() -> T, T> WriteWhereClause<T> for F {}
fn takes_any_requires_static<F>(_: F, any_lt: F::Output) -> &'static str
where
    //     Where-clause rejected by HIR lowering. This must not be soundness-critical,
    //     as elaboration can give us the exact same where-clause regardless. It should
    //     simply not be possible to prove it.
    // F: for<'a> FnOnce() -> &'a String,
    //     Elaborating the below where-clause does work. This is #136547.
    F: for<'a> WriteWhereClause<&'a str>,
{
    any_lt
}

fn dangle() -> &'static str {
    let temp = String::from("temporary");
    takes_any_requires_static(|| "whatever", temp.as_str())
}

fn main() {
    println!("{:?}", dangle());
}

The type of || "whatever" is Closure<for<'b> fn() -> &'b str>. Its builtin impl is not well-formed as the impl signature does not constrain 'a.

impl<'a, T> FnOnce<()> for Closure<for<'b> fn() -> &'b str> {
     type Output = &'a T;
}

---

• This is an exploit of associated types have to be fully constrained lcnr/random-rust-snippets#12, which I previously only considered to be a limitation of future language extensions
• It's related to 'static closures/FnDefs/futures with non-'static return type are unsound #84366 and will likely be fixed in the same way
• It would be interesting to see whether this can be exploited if we were to fix super trait bounds can result in unconstrained regions #136547. Because if not, we may be able to instead warn on (shallow) FnOnce super-trait bounds which would be considered to be unconstraining by themselves

[maxdexh]

fn takes_any_requires_static<F: for<'a> WriteWhereClause<&'a str>>(_: F, any_lt: F::Output) -> &'static str {
    any_lt
}

fn dangle() -> &'static str {
    let temp = String::from("temporary");
    takes_any_requires_static(|| "whatever", temp.as_str())
}

Wow, that is very insightful. I was assuming that F::Output was only constructible by calling F. Very surprised that it just literally accepts any reference you throw at it ;D.

pub trait Producer<T>: FnOnce() -> T {}
impl<T, F: FnOnce() -> T> Producer<T> for F {}

fn make_static<T, P: for<'a> Producer<&'a T>>(_: P, any_borrow: P::Output) -> &'static T {
    any_borrow
}

pub fn main() {
    let victim = vec![vec![1]];
    let long_lived = make_static(|| unreachable!(), &victim);
    drop(victim);
    println!("{:?}", long_lived);
}

Very cool, this can be used to write the most readable UB I've ever seen!

@lcnr I do wonder though, why do you have these in a personal repo instead of reporting them here? I guess that gives me an extra place to check when reporting soundness bugs in the future 🙃

Oh, and I also wonder what makes the Fn* traits special here, since there are many traits with this general shape (e.g. IntoIterator is really similar to FnOnce). Is it just closures?

[lcnr]

I do wonder though, why do you have these in a personal repo instead of reporting them here?

the issues in that repo are not bugs or unsoundnesses, they are interesting fun facts about Rust 😁 as in, lcnr/random-rust-snippets#12 is something that limits future designs, it isn't unsound by itself as user-written impls can't have unconstrained associated types

Oh, and I also wonder what makes the Fn* traits special here, since there are many traits with this general shape (e.g. IntoIterator is really similar to FnOnce). Is it just closures?

The Fn* traits are special as their implementation is builtin to the compiler. And these builtin implementations are broken. There is no way to manually write an impl which can prove T: for<'a> Trait<Assoc = &'a ()>.

[theemathas]

Oddly enough, I'm having trouble getting the UB to happen by using functions or async blocks (instead of closures). It seems to be just specifically closures that cause this issue.

[lcnr]

Oddly enough, I'm having trouble getting the UB to happen by using functions or async blocks (instead of closures). It seems to be just specifically closures that cause this issue.

This is the case as for functions, we also check whether the return type would have unconstrained lifetimes, and if so, the lifetime is forced to be early-bound, as in, it's added as a generic parameter of the function type (ty::FnDef)

fn foo<'a>(x: &'a ()) -> &'a str { x } // late-bound lt
fn bar<'a>() -> &'a str { "hi there" } // early-bound lt

// this gets desugared to pretty much
struct foo;
impl<'a> FnOnce<(&'a (),)> for foo {
    type Output = &'a ();
    // ...
}

struct bar<'a>;
impl<'a> FnOnce<()> for bar<'a> {
    type Output = &'a ();
    // ...
}

[maxdexh]

the issues in that repo are not bugs or unsoundnesses, they are interesting fun facts about Rust 😁 as in, lcnr/random-rust-snippets#12 is something that limits future designs, it isn't unsound by itself as user-written impls can't have unconstrained associated types

Oh, I misread the issue. I just saw the functions and thought "yea that looks unsound", but didn't see that it was to demonstrate a compile error. I thought my issue was a duplicate 😄

Still a very cool repo! I have some of my own snippets/toolbox I go back to when I encounter things that I think might cause soundness bugs

[theemathas]

This issue looks kind of similar to #130347

[maxdexh]

pub trait Producer<T>: FnOnce() -> T {}
impl<T, F: FnOnce() -> T> Producer<T> for F {}

fn make_static<T, P: for<'a> Producer<&'a T>>(_: P, any_borrow: P::Output) -> &'static T {
    any_borrow
}

pub fn main() {
    let victim = vec![vec![1]];
    let long_lived = make_static(|| unreachable!(), &victim);  // R1
    drop(victim);  // R2
    println!("{:?}", long_lived);
}

While testing the simplified version, I realized that I got the earliest affected version wrong. Here is an exhaustive list of results for all versions from 1.60-1.72.1:

• 1.60.0-1.66.*: Expected &Vec<Vec<i32>>, got &'a Vec<Vec<i32>> on R1 (1.63.0-1.66.1 also give a move after borrow on R2)
• 1.67.0-1.69.*: Already Affected
• 1.70.0-1.72.0: ICE (though the ICE changes in 1.71.0)
• 1.72.1: ICE is fixed, but affected again (clearly implied bounds: do not ICE on unconstrained region vars #115559)

I'm not sure how I missed this, because in my command history I found that 1.69 was the first old version I tried.

I must have done something very wrong, because unlike what I initially described, no version except those described here ICE.

[maxdexh]

Regression is in nightly-2022-11-05.

[maxdexh]

Don't feel like building the compiler right now, but 6718ea1 looks interesting

[lcnr]

yeah, it should be #101834 👍