titzer@ -- setting current milestone (M50) as the milestone since it is a High Pri bug. Please feel free to change.

titzer: 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

This was introduced in https://codereview.chromium.org/1928513002.

As far as I can tell, these loads and stores perform no bounds checking.

(Er sorry, I blamed the wrong CL, but WasmGraphBuilder::MemBuffer and calls to that seem to be the issue)

Aaand I retract both of the above comments. The actual bug is that the Uint32 can even be constructed. The checked load/store instructions assume that the size of the backing store is properly aligned for the access type, so it only checks the index:

ldr x2, pc+40 (addr 0x00007f229bb6fd08)
movz x1, #0x0
movz x0, #0x539
cmp w1, #0x1 (1)
b.hs #+0x8 (addr 0x7f229bb6fcf8)
str w0, [x2, w1, uxtw]
ret

Oddly, I see the same issue on x86, but ASAN doesn't yell at me, hmmm.

(The reason for ASAN not yelling is obviously that ASAN doesn't instrument generated code - this is why it is only caught in the simulator)

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

This doesn't affect Chrome as shipped because it requires --expose-wasm. Modifying the repro to use plain asm.js results in an exception being thrown as expected.

ClusterFuzz has detected this testcase as flaky and is unable to reproduce it in the original crash revision. Skipping fixed testing check and marking it as potentially fixed.

Detailed report: https://cluster-fuzz.appspot.com/testcase?key=5937108203601920

Fuzzer: mbarbella_js_mutation
Job Type: linux_asan_d8_v8_arm64_dbg
Platform Id: linux

Crash Type: Heap-buffer-overflow WRITE 4
Crash Address: 0x60300003e9f3
Crash State:
  v8::internal::Simulator::LoadStoreHelper
  v8::internal::Simulator::ExecuteInstruction
  v8::internal::Simulator::CheckPCSComplianceAndRun
  
Recommended Security Severity: High


Unminimized Testcase: https://cluster-fuzz.appspot.com/download/AMIfv94U2iaqrR8m7ltZSaIOddV9MJ4-komDCa39d3-pKiLLxEy3aJAja_3r_Z4PqeEWAKKlBWeOCYCxzVgEiIUX0kUEP6mmO7lEvMDE8l4KlvwqKN5kTWA6HDt6fnQ0c1yy7xvuo4J_nBRGxkfmNZY3bxr-ZSoIEIm9Gw0zjVafjaY2uQF9CXU


See https://dev.chromium.org/Home/chromium-security/bugs/reproducing-clusterfuzz-bugs for more information.

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

This is fixed, right?

This should be fixed because we:

A.) Generate a RangeError when trying to create Int32Array of unaligned size
B.) Mask accesses in asm-wasm generated code to preserve asm.js behavior.

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