I don't like that project. Through the ways of the internet is somehow got some spotlight, but AFAIK it doesn’t really contain any novelty, but builds on the oldest type-system unsoundness in the books, which is a known issue for almost a decade longer than cve-rs exists
opened 05:37PM - 28 May 15 UTC
A-type-system
P-medium
I-unsound
C-bug
A-variance
S-bug-has-test
T-types
The combination of variance and implied bounds for nested references opens a hol… e in the current type system:
``` rust
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(&'static &'a (), &'a T) -> &'static T = foo;
f(UNIT, x)
}
```
This hole has been fixed in #129021 for non-higher-ranked function pointers. The underlying issue still persists.
```rust
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(_, &'a T, &()) -> &'static T = foo;
f(UNIT, x, &())
}
fn main() {}
```
---
Update from @pnkfelix :
While the test as written above is rejected by Rust today (with the error message for line 6 saying "in type `&'static &'a ()`, reference has a longer lifetime than the data it references"), that is just an artifact of the original source code (with its explicit type signature) running up against _one_ new WF-check.
The fundamental issue persists, since one can today write instead:
``` rust
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(_, &'a T) -> &'static T = foo;
f(UNIT, x)
}
```
(and this way, still get the bad behaving `fn bad`, by just side-stepping one of the explicit type declarations.)
I mean, I guess if you aren’t up for the thought exercise yourself, reading through cve-rs can help with figuring out why circumventing the borrow checker lets you do essentially anything (e.g. arbitrary transmutations, etc…)
3 Likes