implied bound related unsoundness

[cushionbadak]

This is almost identical to the unsound example test case for issue-25860. The difference is that this variant only began compiling successfully since nightly-2020-06-24, whereas the existing known unsoundness already compiles since nightly-2015-02-18 (rustc 1.0.0).

I tried this code:

static UNIT: &'static &'static () = &&();

fn foo<'a, 'b, T>(_: &'a &'b (), v: &'b T) -> &'a T { v }

fn bad<'a, T>(x: &'a T) -> &'static T {
    let f: fn(_, &T) -> &'static T = foo;
    f(UNIT, x)
}

fn main() {
    let r: &'static String;
    {
        let s = String::from("temporary");
        r = bad(&s);
        println!("while alive: {}", r);
    }
    println!("use-after-free reads: {}", r);
}

The only difference from that test case is the number of parameters and arguments in foo.
For reference:

rust/tests/ui/implied-bounds/implied-bounds-on-nested-references-plus-variance-2.rs

Lines 6 to 11 in 4f84d9f

	fn foo<'a, 'b, T>(_: &'a &'b (), v: &'b T, _: &()) -> &'a T { v }
	fn bad<'a, T>(x: &'a T) -> &'static T {
	let f: fn(_, &'a T, &()) -> &'static T = foo;
	f(UNIT, x, &())
	}

I expected to see this happen: compilation should fail

Instead, this happened: the program compiled and produced the following use-after-free output:

while alive: temporary
use-after-free reads: j��;g

Meta

rustc --version --verbose:

rustc 1.98.0-nightly (6bdf43094 2026-06-01)
binary: rustc
commit-hash: 6bdf43094fae65d298bc430362f116176cd25a3c
commit-date: 2026-06-01
host: x86_64-unknown-linux-gnu
release: 1.98.0-nightly
LLVM version: 22.1.6

Bisection Results

Command: cargo bisect-rustc --start=2018-01-01 --end=2020-06-30 --regress=success --preserve --script rustc -- bug.rs

Regression in: nightly-2020-06-24.

Log

searched toolchains nightly-2018-01-01 through nightly-2020-06-30


********************************************************************************
Regression in nightly-2020-06-24
********************************************************************************

fetching https://static.rust-lang.org/dist/2020-06-23/channel-rust-nightly-git-commit-hash.txt
nightly manifest 2020-06-23: 40 B / 40 B [==============================================================================================================================================] 100.00 % 1.40 MB/s converted 2020-06-23 to 6bb3dbfc6c6d8992d08431f320ba296a0c2f7498
fetching https://static.rust-lang.org/dist/2020-06-24/channel-rust-nightly-git-commit-hash.txt
nightly manifest 2020-06-24: 40 B / 40 B [==============================================================================================================================================] 100.00 % 2.07 MB/s converted 2020-06-24 to ff5b446d2fdbd898bc97a751f2f72858de185cf1
looking for regression commit between 2020-06-23 and 2020-06-24
fetching (via remote github) commits from max(6bb3dbfc6c6d8992d08431f320ba296a0c2f7498, 2020-06-21) to ff5b446d2fdbd898bc97a751f2f72858de185cf1
ending github query because we found starting sha: 6bb3dbfc6c6d8992d08431f320ba296a0c2f7498
get_commits_between returning commits, len: 6
  commit[0] 2020-06-22: Auto merge of #73415 - ehuss:update-cargo, r=ehuss
  commit[1] 2020-06-22: Auto merge of #73594 - Aaron1011:revert/move-fn-self-msg, r=Manishearth
  commit[2] 2020-06-23: Auto merge of #73007 - yoshuawuyts:socketaddr-from-string-u16, r=sfackler
  commit[3] 2020-06-23: Auto merge of #73635 - Dylan-DPC:rollup-b4wbp42, r=Dylan-DPC
  commit[4] 2020-06-23: Auto merge of #73643 - Manishearth:rollup-68dr8fz, r=Manishearth
  commit[5] 2020-06-23: Auto merge of #73644 - ollie27:rustdoc_alias_filter, r=GuillaumeGomez
ERROR: no CI builds available between 6bb3dbfc6c6d8992d08431f320ba296a0c2f7498 and ff5b446d2fdbd898bc97a751f2f72858de185cf1 within last 167 days

[cushionbadak]

After building rustc from source, the regression is introduced by PR-72493, which is in rollup PR-73643.

With PR-72493, it compiles, UAF at runtime:

ubuntu@ip-172-31-55-24:~/rust$ git rev-parse HEAD
903823c59bcb9890df2a6fadcf7aa22f74eed67f
ubuntu@ip-172-31-55-24:~/rust$ ./build/x86_64-unknown-linux-gnu/stage1/bin/rustc  -Vv
rustc 1.46.0-dev
binary: rustc
commit-hash: unknown
commit-date: unknown
host: x86_64-unknown-linux-gnu
release: 1.46.0-dev
LLVM version: 10.0
ubuntu@ip-172-31-55-24:~/rust$ ./build/x86_64-unknown-linux-gnu/stage1/bin/rustc  ../f/bug.rs
ubuntu@ip-172-31-55-24:~/rust$ ./bug
while alive: temporary
use-after-free reads: Ж25�

Before, it rejected like this:

ubuntu@ip-172-31-55-24:~/rust$ git rev-parse HEAD
59e87c0b81dd7f42d03f9b8d10cf3636feff9dd0
ubuntu@ip-172-31-55-24:~/rust$ ./build/x86_64-unknown-linux-gnu/stage1/bin/rustc  -Vv
rustc 1.46.0-dev
binary: rustc
commit-hash: unknown
commit-date: unknown
host: x86_64-unknown-linux-gnu
release: 1.46.0-dev
LLVM version: 10.0
ubuntu@ip-172-31-55-24:~/rust$ ./build/x86_64-unknown-linux-gnu/stage1/bin/rustc  ../f/bug.rs
error[E0308]: mismatched types
 --> ../f/bug.rs:6:38
  |
6 |     let f: fn(_, &T) -> &'static T = foo;
  |            -----------------------   ^^^ expected concrete lifetime, found bound lifetime parameter
  |            |
  |            expected due to this
  |
  = note: expected fn pointer `for<'r> fn(_, &'r T) -> &'static T`
                found fn item `for<'a, 'b> fn(&'a &'b (), &'b _) -> &'a _ {foo::<_>}`

error: aborting due to previous error

For more information about this error, try `rustc --explain E0308`.

[Dnreikronos]

I was able to reproduce this locally, and I believe it's the same underlying bug raised on #25860 (implied bounds + variance), specifically the higher-ranked case. Linking the two so they don't get lost.

What is found was #129021 added a well-formedness check on the reified fn pointer in borrowck, and that already rejects the non-higher-ranked forms. For example, this one errors now:

let f: fn(_, &'a T) -> &'static T = foo;  // error: 'a must outlive 'static

The interesting part is that the same PR knew the higher-ranked case was still open: it added a known-bug: #25860 test at tests/ui/implied-bounds/implied-bounds-on-nested-references-plus-variance-2.rs, and its own comment in rustc_borrowck::type_check says the check "only works when we're casting to a non-higher-ranked fn ptr."

The case raised here it's exactly that same problem. The elided reference makes the target fn pointer higher-ranked, and it sails right through:

let f: fn(_, &T) -> &'static T = foo;     // still compiles

The reason it compiles: the implied bound the call relies on ends up under the for<> binder, and fn-pointer WF doesn't track it there. wf.rs even has a long-standing comment about this exact thing, already pointing at #25860: "there is no way for us to express a fn type complete with the implied bounds that it is assuming."

So I think this is the higher-ranked residual of #25860. I would like to have an opinion from the T-types folks about the decision whether to keep this issue as the tracked minimal repro for that form or fold it into #25860.

[cushionbadak]

Agreed the main root cause is issue-25860, the repro is nearly identical to the testcase as I mentioned.

But I don't think this is simply the 25860 bug resurfacing. The similar testcase has compiled at least as far back as I tested (2018), whereas this shape only started compiling at pr-72493 (2020-06, the leak-check move). So despite looking the same, this form was rejected for years until it was newly exposed.

Even if this folds into 25860, that pr-72493 regression point seems worth recording.

[Dnreikronos]

Agreed the main root cause is issue-25860, the repro is nearly identical to the testcase as I mentioned.

But I don't think this is simply the 25860 bug resurfacing. The similar testcase has compiled at least as far back as I tested (2018), whereas this shape only started compiling at pr-72493 (2020-06, the leak-check move). So despite looking the same, this form was rejected for years until it was newly exposed.

Even if this folds into 25860, that pr-72493 regression point seems worth recording.

Yeah, make sense!
Seems like that the -2.rs shape has been broken for some time already(years), but this higher-ranked form was actually rejected until #72493 (the leak-check move) in 2020, so it's a real regression, not something that was always compiling.

I separated like this: #25860 is the underlying logical hole (implied bounds + variance + fn-pointer coercion). The old leak check seems to have been guarding this particular higher-ranked coercion by accident. Before #72493 it failed with error[E0308]: ... expected concrete lifetime, found bound lifetime parameter. #72493 moved the leak check out of higher-ranked subtyping and into coherence and candidate evaluation, and that removed the incidental guard, which is what exposed this form.

I believe that the right approach would look like this: probably we shouldn't revert of #72493. The leak check was only catching this by accident, and #72493 moved it on purpose. The fix #25860 has always needed is the right one here too: make fn-pointer well-formedness track the implied bound under the for<> binder, so the coercion gets rejected on WF grounds instead of incidentally by the leak check.

So two facts, both worth keeping. The root cause is the #25860 family. This specific form is a #72493 regression that was correctly rejected for years. The regression isn't a footnote to the root cause, and I agree it should be recorded whether or not the issue ends up folded.

What you think, @cushionbadak?

[cushionbadak]

Good. I prefer separating the regression from the root cause in bug reporting, but I think the triage is out of my hands.

[rustbot]

Assigning P-medium (discussion on Zulip).