Automatically applying components based on crash stacktrace and information from OWNERS files.

If this is incorrect, please apply the Test-Predator-Wrong-Components label.

This is a serious security regression. If you are not able to fix this quickly, please revert the change that introduced it.

If this doesn't affect a release branch, or has not been properly classified for severity, please update the Security_Impact or Security_Severity labels, and remove the ReleaseBlock label. To disable this altogether, apply ReleaseBlock-NA.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

hpayer can you triage this and assign an appropriate owner? Thanks.

Assigning to the current CF sheriff.

Cannot reproduce on rodete, because instrumented libraries are missing.

Michi, I know that you are quite busy, but can you help out bisecting this on trusty?

awhalley@ - is this okay to punt to M65?

No need to block stable on it, given we've not got a fix. If there's a well baked fix landed soon we could consider for a 64 merge then.

This is a serious security regression. If you are not able to fix this quickly, please revert the change that introduced it.

If this doesn't affect a release branch, or has not been properly classified for severity, please update the Security_Impact or Security_Severity labels, and remove the ReleaseBlock label. To disable this altogether, apply ReleaseBlock-NA.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

Nothing I can do here without msan support on rodete. Back to the triaging queue.

+aarya@ in case Bugs-- has any update on msan support on rodete.

This bug should in principle affect all but iOS, right?

Let's aim for M65 for this. Please merge-request for 64 if its needed and if there is a well baked fix, but per #11, let's target 65 and marking this as non-stable blocker for 64. 

This is a dupe of  issue 610214  (which was already marked as verified but not yet fixed).

What is happening here is when we are near the stack limit in an optimized function and we call another function with so many arguments that it "overflows" the allocated JS stack buffer before we manage to do a call (which will do a next stack limit check).

This is a simulator-only issue because on the real hardware where we use normal stack as a JS stack we will trigger the real stack overflow during attempt to push a next argument on the stack.
I think we can remove the security labels and decrease the priority.

Assigning to TF team to handle this case if necessary.

Aha. So this is basically a dupe of 788071.
Thanks for investigating!

mvstanton: Uh oh! This issue still open and hasn't been updated in the last 19 days. This is a serious vulnerability, and we want to ensure that there's progress. Could you please leave an update with the current status and any potential blockers?

If you're not the right owner for this issue, could you please remove yourself as soon as possible or help us find the right one?

If the issue is fixed or you can't reproduce it, please close the bug. If you've started working on a fix, please set the status to Started.

Thanks for your time! To disable nags, add the Disable-Nags label.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

According to ishell's comment, this is a duplicate of a fixed issue. Closing appropriately.

No, the issue is not actually fixed. 
It does not fail on the test case from  issue 610214  anymore but the problem on simulators is still there.

Oh sorry. Okay. Fixing this simulator-only issue everywhere would be a lot of work (per discussion with mstarzinger@chromium.org), and only of benefit to the bots. It's also not a security issue. ClusterFuzz occasionally hits this issue, but not at a frequency which stops progress. 

Therefore, I'll close this issue as WontFix, and we can dupe future arm simulator stack-overflows to this one.

I am not sure if this really is a simulator-only bug.
In 788071 we came to the conclusion that this can also happen in JS and wasm code, and I uploaded a PoC for wasm.
Basically whenever we are near the stack limit and then call a function with many arguments (which end up on the stack) we can run into the red zone without triggering a stack overflow.

Very good, reopening, as it appears we need to fix this.

Any update here?  Please note that M65 Stable is nearing.  Please take a look asap.

This issue exists since a very long time. It's not a release blocker.

A High is Pri-1, per https://chromium.googlesource.com/chromium/src/+/master/docs/security/severity-guidelines.md. Please note that we have a 60-day guarantee for High bugs.

mvstanton: Uh oh! This issue still open and hasn't been updated in the last 14 days. This is a serious vulnerability, and we want to ensure that there's progress. Could you please leave an update with the current status and any potential blockers?

If you're not the right owner for this issue, could you please remove yourself as soon as possible or help us find the right one?

If the issue is fixed or you can't reproduce it, please close the bug. If you've started working on a fix, please set the status to Started.

Thanks for your time! To disable nags, add the Disable-Nags label.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

Let's merge this with 788071, and try to find a solution there.

This bug has been closed for more than 14 weeks. Removing security view restrictions.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot