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

ChakraCore Servicing Update for 2020.06B #6464

Merged
merged 3 commits into from
Jun 10, 2020

Conversation

rajeshpeter
Copy link
Collaborator

CVE-2020-1219]
Js::PathTypeHandlerBase::SetPrototype should protect against the case where the instance's type is changed as a side-effect of calling newPrototype->GetInternalProperty. Intl.js should not refer directly to the global Intl property, as this may have been modified by the user in such a way that Intl initialization has side-effects. Created an Intl property on the interface object whose value is the built-in Intl object and refer to that in Intl.js instead.

[CVE-2020-1073]
Non-optimized StFld that may change the object's type may be undetected in the loop prepass, resulting in bad AdjustObjType downstream. If the dead store pass detects a final type that's live across a non-optimized StFld, mark the StFld to use a helper that will return true if the object's type is changed, and bail out if the helper returns true. Also ensures there is no type transition live across InitClassMember.

@boingoing boingoing merged commit 906f833 into chakra-core:release/1.11 Jun 10, 2020
boingoing pushed a commit that referenced this pull request Jun 19, 2020
…for 2020.06B

Merge pull request #6464 from rajeshpeter:servicing/2006

CVE-2020-1219]
Js::PathTypeHandlerBase::SetPrototype should protect against the case where the instance's type is changed as a side-effect of calling newPrototype->GetInternalProperty. Intl.js should not refer directly to the global Intl property, as this may have been modified by the user in such a way that Intl initialization has side-effects. Created an Intl property on the interface object whose value is the built-in Intl object and refer to that in Intl.js instead.

[CVE-2020-1073]
Non-optimized StFld that may change the object's type may be undetected in the loop prepass, resulting in bad AdjustObjType downstream. If the dead store pass detects a final type that's live across a non-optimized StFld, mark the StFld to use a helper that will return true if the object's type is changed, and bail out if the helper returns true. Also ensures there is no type transition live across InitClassMember.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants