cve-rs: Fix unsound lifetime extension in HRTB function pointer coercion

[kstrafe]

Doesn't fix but slightly patches #25860

= Problem =

The compiler allowed unsound coercions from function items/pointers with nested reference parameters to HRTB function pointers, enabling arbitrary lifetime extension to 'static. This was demonstrated by the cve-rs exploit:

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

// This coercion was allowed but unsound:
let f: for<'x> fn(_, &'x T) -> &'static T = foo;

The issue occurs because nested references like &'a &'b () create an implied outlives bound 'b: 'a. When coercing to an HRTB function pointer, this constraint was not validated, allowing the inner lifetime to be extended arbitrarily.

= Solution =

This commit adds validation during function pointer coercion to detect and reject unsound HRTB coercions involving implied bounds from nested references.

The fix works in two stages:

1. Extract implied outlives bounds from nested references in the source function signature using a new implied_bounds module in rustc_infer.

2. During HRTB function pointer coercion in rustc_hir_typeck, check if:

   • Source has nested references with implied bounds
   • Target does NOT preserve the nested reference structure
   • If both conditions hold, reject the coercion as unsound

This refined approach allows safe coercions like:
fn(&'a &'b T) -> for<'r, 's> fn(&'r &'s T) (preserves structure)

While blocking unsound ones like:
fn(&'a &'b T) -> for<'r> fn(&'r T) (collapses lifetimes)

== Implementation Details ==

New module: compiler/rustc_infer/src/infer/outlives/implied_bounds.rs

• extract_nested_reference_bounds(): Recursively extracts implied bounds from nested references, tuples, and ADT type arguments

Modified: compiler/rustc_hir_typeck/src/coercion.rs

• check_hrtb_implied_bounds(): Validates HRTB coercions in both coerce_from_fn_pointer() and coerce_from_fn_item()
• Only rejects when nested reference structure is not preserved in target

== Testing ==

• Added comprehensive test: tests/ui/implied-bounds/cve-rs-lifetime-expansion.rs reproducing and validating the fix for the cve-rs exploit
• Updated multiple existing tests to reflect corrected behavior
• All 19,700+ UI tests pass with only 1 unrelated platform-specific failure
• Verified no regressions in common patterns and real-world crate usage (e.g., syn)

== Notes ==

This fix is conservative but precise; it only rejects coercions that would violate soundness by collapsing nested lifetime relationships. Valid code patterns, even those using nested references with HRTB, continue to compile.

The fix addresses the specific exploit in #25860 (cve-rs lifetime expansion) and is distinct from the related but separate issue #84591 (HRTB on subtraits).

[rustbot]

r? @davidtwco

rustbot has assigned @davidtwco.
They will have a look at your PR within the next two weeks and either review your PR or reassign to another reviewer.

Use r? to explicitly pick a reviewer

[rustbot]

⚠️ Warning ⚠️

• There are issue links (such as #123) in the commit messages of the following commits.
  Please move them to the PR description, to avoid spamming the issues with references to the commit, and so this bot can automatically canonicalize them to avoid issues with subtree.
  • 16fb05e

[fmease]

r? types

[Kivooeo]

can we run bors try, I'm so out of curiosity to see results of it

[mati865]

#25860 has no mentions of cve-rs. Please check your PR for AI hallucinations before you publish it.

[bend-n]

ive checked out your PR, and while you have fixed the first example, this example,

fn foo<'out, 'input, T>(_dummy: &'out (), value: &'input T) -> (&'out &'input (), &'out T) {
    (&&(), value)
}

fn bad<'short, T>(x: &'short T) -> &'static T {
    let foo1: for<'out, 'input> fn(&'out (), &'input T) -> (&'out &'input (), &'out T) = foo;
    let foo2: for<'input> fn(&'static (), &'input T) -> (&'static &'input (), &'static T) = foo1;
    let foo3: for<'input> fn(&'static (), &'input T) -> (&'input &'input (), &'static T) = foo2;
    let foo4: fn(&'static (), &'short T) -> (&'short &'short (), &'static T) = foo3;
    foo4(&(), x).1
}

still compiles fine.

[oli-obk]

This is a very targetted fix for most of the tests we have. Most tests can quickly be reproduced after this PR by wrapping some types in tuples. We can add more patches on top, but it's unfortunately not a full fix (which, even knowing about your patch I believe will still be impossible to fix on the old trait solver)

That said,

• we have golfed cve-rs before and are happy to do it again
• it makes the unsoundness less likely to occur
• if perf effects are small (ignoring coercions stress test)

I think we should still review and likely merge it, even if it sadly doesn't actually fix the issue.

@bors try @rust-timer queue

[rust-timer]

Awaiting bors try build completion.

@rustbot label: +S-waiting-on-perf

[rust-bors]

⌛ Trying commit 16fb05e with merge 6ba65b7…

To cancel the try build, run the command @bors try cancel.

Workflow: https://github.com/rust-lang/rust/actions/runs/18402578832

[oli-obk]

Before actually reviewing the logic for unintended side effects and maintainability, I would prefer it if you could do some cleanups condensing the logic to its bare necessities, as it currently contains a lot of unnecessary collection of information

In the same vein, is there some duplication with other implied bounds logic elsewhere in the compiler?

View changes since this review

[oli-obk]

Why does this allow dead code?

[oli-obk]

I don't understand the comment or the reason for this test module

[oli-obk]

Please avoid allocating a vec just to check that it is empty.