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

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

Automatically assigning owner based on suspected regression changelist https://chromium.googlesource.com/v8/v8/+/184de6af7348d0f382144ea3848f5e71891d228a ([objects] Remove some obsolete {Code} setter methods.).

If this is incorrect, please remove the owner and apply the Test-Predator-Wrong-CLs label.

Pretty sure this is unrelated to the CL referenced in comment #2.

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

clemensh@, could you take a looks? Seems pretty similar to 739186.
Please feel free to re-assign.

clemensh: Are you not the right person to handle this bug? We want to get some movement on it, so that we can meet our promise of resolving High severity bugs in under 60 days. (https://chromium.googlesource.com/chromium/src/+/master/docs/security/severity-guidelines.md#High-severity) Thank you!

I don't think that this is related to 739186. The stack traces just look similar because both are executed in the arm64 interpreter.

I actually tried to bisect this last week, and it bisected back to a clang roll in 2016. Before that, MSan did not report anything, but the renderer still crashed. So I guess that the bug was already there before, but it's hard to bisect further back.
Also, this only reproduces in MSan builds, but MSan builds have no debug information (is_msan cannot be combined with is_debug), which complicates things even more.

I will spend some more time on this today.

Debugged this further now. This is a stack overflow.
Thanks to Michi and Andreas for their help in debugging this.

The code crashes at the instruction
0x00007f106bf44c30  f92d6f80            str x0, [jssp, #23256]

At this point, jssp is 0x00007f108f7fc520.

It was last modified here, where jssp is decreased by 0x8008 bytes (== 32776 bytes):
0x00007f106bf426f8  d2900110            movz x16, #0x8008
0x00007f106bf426fc  cb10039c            sub jssp, jssp, x16

The js limit of the isolate is 0x00007f108f803800.

jssp + 23256 (the address stored to) is 0x00007f108f801ff8.

The instruction before stored at jssp + 23264, which is 0x00007f108f802000, and seems to be just the boundary of accessible memory.
Hence 0x00007f108f802000..0x00007f108f803800 is the red zone of 0x1800 bytes (==6144 bytes).

The code of the function where this happens just has this one line:
"dummy".valueOf(0, 1, 2, 3, [...], 4095);

The stack space of 32776 bytes is allocated to hold the arguments of the "valueOf" call.
It seems that an additional stack check is missing at that point.

Assigning to Michi to decide what needs to happen to prevent this.

This issue exists since a long time. This is not a release blocker.

Even though we do something special about big frames in wasm code (an "extended stack check" in the function prologue), a stack overflow can still happen if we call a function with too many arguments.
Reproducer attached (works with "--stack-size=8192" on my machine).

Deleted: wasm_call_stack_overflow.patch 2.0 KB

wasm_call_stack_overflow.patch 2.0 KB Download

ClusterFuzz has detected this issue as fixed in range 526071:526088.

Detailed report: https://clusterfuzz.com/testcase?key=4843066812006400

Fuzzer: inferno_layout_test_unmodified
Job Type: linux_msan_content_shell_drt
Platform Id: linux

Crash Type: UNKNOWN WRITE
Crash Address: 0x7f36c6a15ff8
Crash State:
  v8::internal::Simulator::LoadStoreHelper
  v8::internal::Simulator::Run
  v8::internal::Simulator::CallVoid
  
Sanitizer: memory (MSAN)

Recommended Security Severity: High

Regressed: https://clusterfuzz.com/revisions?job=linux_msan_content_shell_drt&range=518240:518474
Fixed: https://clusterfuzz.com/revisions?job=linux_msan_content_shell_drt&range=526071:526088

Reproducer Testcase: https://clusterfuzz.com/download?testcase_id=4843066812006400

See https://github.com/google/clusterfuzz-tools for more information.

If you suspect that the result above is incorrect, try re-doing that job on the test case report page.

ClusterFuzz testcase 4843066812006400 is verified as fixed, so closing issue as verified.

If this is incorrect, please add ClusterFuzz-Wrong label and re-open the issue.

The underlying issue discussed in #10 is not fixed yet. 

This bug looks very close to  Issue 801790 , and I think was correctly labeled as a High (as 801790 is). Are they duplicates? mstazinger, please feel free to dup the newer bug into this one if they are.

#11: Just because the bug is old, does not mean it's Low severity.

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.

mstarzinger: Uh oh! This issue still open and hasn't been updated in the last 84 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

We commit ourselves to a 60 day deadline for fixing for high severity vulnerabilities, and have exceeded it here. If you're unable to look into this soon, could you please find another owner or remove yourself so that this gets back into the security triage queue?

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

 Issue 801790  has been merged into this issue.

So basically what we need to do is emitting a "special" stack check before pushing too many arguments on the stack. That stack check would know an estimate of the needed stack size, and would check whether {sp} minus that size is still above the stack limit, and trigger a stack overflow otherwise.
Does that sound correct?

mstarzinger: Uh oh! This issue still open and hasn't been updated in the last 99 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

clemensh@: Thanks for looking at this, is it okay if I assign it to you? It would be really good to get some progress going on it, and if there is somebody else better able to fix it then of course feel free to re-assign.

 Issue 823027  has been merged into this issue.

clemensh@, could you please take a look once you get back from the vacation?

I started looking into this. Have an idea how to fix it, but I am not sure I fully understand what is going on. For wasm, it even crashes if we just pass 10 parameters. Stack checks are there, so we should detect a stack overflow before crashing.
Will investigate more tomorrow.

ClusterFuzz is analyzing your testcase. Developers can follow the progress at https://clusterfuzz.com/testcase?key=5898578674057216.

ClusterFuzz is analyzing your testcase. Developers can follow the progress at https://clusterfuzz.com/testcase?key=5433344595329024.

Ok, the wasm test case only crashed because I specified to too bit --stack-size. With the default stack size, I cannot reproduce any crash for wasm. Will look into the JS case now.

I fail to reproduce this for either wasm or JS on ToT, on either release, debug, msan or asan builds.
Hence setting back to WontFix for now, and waiting for ClusterFuzz to find another instance of this.

ClusterFuzz testcase 5948089991692288 is still reproducing on tip-of-tree build (trunk).

If this testcase was not reproducible locally or unworkable, ignore this notification and we will file another bug soon with hopefully a better and workable testcase.

Otherwise, if this is not intended to be fixed (e.g. this is an intentional crash), please add ClusterFuzz-Ignore label to prevent future bug filing with similar crash stacktrace.

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