-
Notifications
You must be signed in to change notification settings - Fork 12.7k
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
Labels
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
changed the title
GAT's can cause use after free
GAT's arent typechecked, and can cause UB
Jan 29, 2020
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
28 tasks
Elinvynia
added
the
I-prioritize
Issue: Indicates that prioritization has been requested for this issue.
label
Jun 9, 2020
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
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Labels
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.
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:
The text was updated successfully, but these errors were encountered: