-
Notifications
You must be signed in to change notification settings - Fork 1.2k
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
August 2018 Security Update #5596
August 2018 Security Update #5596
Conversation
…tion - Google, Inc
LGTM |
@@ -221,6 +244,20 @@ using namespace Js; | |||
this->GetScriptFunctionType()->ChangeEntryPoint(entryPointInfo, entryPoint, isAsmJS); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We lost a bit here because it moved to a different file. No functional difference but we can avoid some duplication and prevent further merge conflicts when this payload goes to Windows: https://devdiv.visualstudio.com/DevDiv/Chakra/_git/ChakraCore/pullrequest/136749?_a=overview #Resolved
Build/NuGet/.pack-version
Outdated
@@ -1 +1 @@ | |||
1.10.1 | |||
1.10.2-rc |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can you please rebase this commit to remove the -rc
and update the commit message?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
…lid pointer read - Internal When merging block data for loops, we may have data from one edge that a sym is non-temp, but from a different edge we know that there is a temp transfer dependency on that sym. This leads to an inconsistency between the sets where we can treat a non-temp sym as a temp. To solve this, I've changed so that when we merge data we check if any transfer dependency sets have a non-temp sym, and if so it should also be treated as non-temp.
When deciding if we can eliminate a bound check we check if the max value for the index is less than the min value for the length. If this is true, we can remove the bound check. In the code we were testing if indexUpperBound <= lengthLowerBound + (-1 - indexLowerBound). If the index lower bound is less than 0 (e.g. if it is INT_MIN because we don't know the range), we may incorrectly eliminate bound checks. This was essentially never kicking in, so I removed the condition altogether.
… OOB read/write - Internal
…e::SetAttributesHelper - Google, Inc.
…bjectSlotGetter Marshalling should not be re-entrant. But due to proxy in the prototype chain - we could have prototype trap invoked and things can get worse from there. We had put no-reentrancy macro in there but that protect us on RS3 and up. In order to fix this, we need to check if the current object is proxy or not - in that case break the chain.
f4c79b0
to
1452676
Compare
1452676
to
cd84156
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Merge pull request #5596 from aneeshdk:servicing/1808_1.10 This update address the following issues in ChakraCore.dll : CVE-2018-8380, CVE-2018-8359, CVE-2018-8385, CVE-2018-8390, CVE-2018-8266, CVE-2018-8384, CVE-2018-8372, CVE-2018-8355 and CVE-2018-8381
Merge pull request #5596 from aneeshdk:servicing/1808_1.10 This update address the following issues in ChakraCore.dll : CVE-2018-8380, CVE-2018-8359, CVE-2018-8385, CVE-2018-8390, CVE-2018-8266, CVE-2018-8384, CVE-2018-8372, CVE-2018-8355 and CVE-2018-8381
This update address the following issues in ChakraCore.dll : CVE-2018-8380, CVE-2018-8359, CVE-2018-8385, CVE-2018-8390, CVE-2018-8266, CVE-2018-8384, CVE-2018-8372, CVE-2018-8355 and CVE-2018-8381