Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

GAT's arent typechecked, and can cause UB #68641

Closed
Tracked by #44265
DutchGhost opened this issue Jan 29, 2020 · 0 comments · Fixed by #72788
Closed
Tracked by #44265

GAT's arent typechecked, and can cause UB #68641

DutchGhost opened this issue Jan 29, 2020 · 0 comments · Fixed by #72788
Labels
A-GATs Area: Generic associated types (GATs) C-bug Category: This is a bug. F-generic_associated_types `#![feature(generic_associated_types)]` a.k.a. GATs I-unsound Issue: A soundness hole (worst kind of bug), see: https://en.wikipedia.org/wiki/Soundness requires-nightly This issue requires a nightly compiler in some way. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.

Comments

@DutchGhost
Copy link
Contributor

It looks like Generic Associated Types aren't validated on whether the specified type on the impl-side indeed implements the traits as written down in the definition of the associated type.

The following program shows a use-after-free of a String:

#![feature(generic_associated_types)]
trait UnsafeCopy {
    type Item<'a>: Copy;
    
    fn copy<'a>(item: &Self::Item<'a>) -> Self::Item<'a> {
        *item
    }
}

impl <T> UnsafeCopy for T {
    type Item<'a> = T;
}

fn main() {
    let mut s = String::from("Hello world!");
    
    let copy = String::copy(&s);
    
    // Do we indeed point to the samme memory?
    assert!(s.as_ptr() == copy.as_ptr());
    
    // Any use of `copy` is certeinly UB after this
    drop(s);
    
    // UB UB UB UB UB!!
    println!("{}", copy);
}
@DutchGhost DutchGhost changed the title GAT's can cause use after free GAT's arent typechecked, and can cause UB Jan 29, 2020
@jonas-schievink jonas-schievink added C-bug Category: This is a bug. F-generic_associated_types `#![feature(generic_associated_types)]` a.k.a. GATs I-unsound Issue: A soundness hole (worst kind of bug), see: https://en.wikipedia.org/wiki/Soundness requires-nightly This issue requires a nightly compiler in some way. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. labels Jan 29, 2020
@Elinvynia Elinvynia added the I-prioritize Issue: Indicates that prioritization has been requested for this issue. label Jun 9, 2020
@LeSeulArtichaut LeSeulArtichaut removed the I-prioritize Issue: Indicates that prioritization has been requested for this issue. label Jun 9, 2020
Manishearth added a commit to Manishearth/rust that referenced this issue Jun 16, 2020
…dation, r=nikomatsakis

Projection bound validation

During selection we use bounds declared on associated types (e.g. `type X: Copy`) to satisfy trait/projection bounds. This would be fine so long as those bounds are checked on any impls/trait objects. For simple cases they are because the bound `Self::X: Copy` gets normalized when we check the impl.

However, for default values with specialization and higher-ranked bounds from GATs or otherwise, we can't normalize when checking the impl, and so we use the bound from the trait to prove that the bound applies to the impl, which is clearly unsound.

This PR makes 2 fixes for this:

1. Requiring that the bounds on the trait apply to a projection type with the corresponding substs, so a bound `for<'a> <Self as X<'a>>::U: Copy` on the trait cannot be used to prove `<T as X<'_>>::U: Copy`.
2. Actually checking that the bounds that we still allow apply to generic/default associated types.

Opening for a crater run.

Closes rust-lang#68641
Closes rust-lang#68642
Closes rust-lang#68643
Closes rust-lang#68644
Closes rust-lang#68645
Closes rust-lang#68656

r? @ghost
Manishearth added a commit to Manishearth/rust that referenced this issue Jun 20, 2020
…dation, r=nikomatsakis

Projection bound validation

During selection we use bounds declared on associated types (e.g. `type X: Copy`) to satisfy trait/projection bounds. This would be fine so long as those bounds are checked on any impls/trait objects. For simple cases they are because the bound `Self::X: Copy` gets normalized when we check the impl.

However, for default values with specialization and higher-ranked bounds from GATs or otherwise, we can't normalize when checking the impl, and so we use the bound from the trait to prove that the bound applies to the impl, which is clearly unsound.

This PR makes 2 fixes for this:

1. Requiring that the bounds on the trait apply to a projection type with the corresponding substs, so a bound `for<'a> <Self as X<'a>>::U: Copy` on the trait cannot be used to prove `<T as X<'_>>::U: Copy`.
2. Actually checking that the bounds that we still allow apply to generic/default associated types.

Opening for a crater run.

Closes rust-lang#68641
Closes rust-lang#68642
Closes rust-lang#68643
Closes rust-lang#68644
Closes rust-lang#68645
Closes rust-lang#68656

r? @ghost
@bors bors closed this as completed in 1a171d0 Jun 21, 2020
@fmease fmease added the A-GATs Area: Generic associated types (GATs) label Nov 2, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-GATs Area: Generic associated types (GATs) C-bug Category: This is a bug. F-generic_associated_types `#![feature(generic_associated_types)]` a.k.a. GATs I-unsound Issue: A soundness hole (worst kind of bug), see: https://en.wikipedia.org/wiki/Soundness requires-nightly This issue requires a nightly compiler in some way. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

5 participants