yangguo@, could you please take a look?

Not sure why this is assigned to me. Forwarding to the *SAN sheriff.

I've seen similar  bug 389595  in the past, it was assigned to you initially, so I just followed that way :)

Thanks for forwarding!

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

Moving into CF sheriff queue.

mstarzinger: Would you mind taking another look or closing if this isn't actionable? (Need an owner since it's in the security queue)

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

mstarzinger@chromium.org: do you have time to look at this / suggest someone else who is suitable to look at this? It's currently in the security queue.

(Also, if it's just a problem in the v8 simulator then we can remove the security labels).

Looks like a simulator-only issue. Removing security labels.

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=5294415890874368

Fuzzer: mbarbella_js_mutation
Job Type: linux_msan_d8
Platform Id: linux

Crash Type: Use-of-uninitialized-value
Crash Address: 
Crash State:
  long v8::internal::Simulator::AddWithCarry<long>
  void v8::internal::Simulator::AddSubHelper<long>
  v8::internal::Simulator::CallVoid
  

Unminimized Testcase: https://cluster-fuzz.appspot.com/download/AMIfv941jbVkNK6JVyJyPtzoNZfzzfkhdFk3oSvnyzragckNQLvf9q3CIJd9ec-vdbPjLurElew1nNWlt1l06-0Fo-BJEiNX_LIjUuXoz71kEgqN7bg_kLtwp3S8XvdU0iOQN8wWFE8GufT9A5rmOMG5fP5obf9ebQ?testcase_id=5294415890874368


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.

The simulator is invoking undefined behavior pervasively with signed overflow of int64. That may be triggering MSAN warnings here. Needs to be fixed with the use of unsigned arithmetic in the simulator.

Hi Ben,

I don't seem to be able to follow the link to see the various traces which will be helpful to reproduce/fix the issue. Can we get access to them?

Also can you add jacob.bramley@arm.com and rodolph.perfetta@arm.com to Cc list. I don't seem to be able to edit the issue.

Fuzzer file is attached.

Deleted: fuzz-04129.js 612 bytes

fuzz-04129.js 612 bytes View Download

I think* I have managed to produce a suitable MSAN build of d8, but (at commit b36237b), no problems are reported with fuzz-04129.js. Is there anything else we should know about how the test should be run? Does it need specific command-line flags?

Thanks,
Jacob



* "msan=1" doesn't work for me out of the box, mostly as a result of problems with the instrumented libraries, but I managed to hack the build system to get it to work. (I verified it with some deliberately-broken code.)

This is how d8 being run at ClusterFuzz:

$ MSAN_OPTIONS=symbolize=0:coverage=0 ./d8 --random-seed=1285131920 --expose-gc --always-opt fuzzer-testcases/fuzz-04129.js

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=5294415890874368

Fuzzer: mbarbella_js_mutation
Job Type: linux_msan_d8
Platform Id: linux

Crash Type: Use-of-uninitialized-value
Crash Address: 
Crash State:
  long v8::internal::Simulator::AddWithCarry<long>
  void v8::internal::Simulator::AddSubHelper<long>
  v8::internal::Simulator::CallVoid
  

Unminimized Testcase: https://cluster-fuzz.appspot.com/download/AMIfv941jbVkNK6JVyJyPtzoNZfzzfkhdFk3oSvnyzragckNQLvf9q3CIJd9ec-vdbPjLurElew1nNWlt1l06-0Fo-BJEiNX_LIjUuXoz71kEgqN7bg_kLtwp3S8XvdU0iOQN8wWFE8GufT9A5rmOMG5fP5obf9ebQ?testcase_id=5294415890874368


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.

Thanks for the command line. I still don't see the failure, though. I just tried with the same command line, except that I have to specify LD_LIBRARY_PATH to get it to use the instrumented C++ library.

Could you tell me the failing revision please? I'd like to try it in case the problem is hidden by chance on later revisions of master.

Crash revision:

Chromium: 388139
V8: 81b163790c20cd525443c009238088a4141dd993

Jacob, did you follow http://dev.chromium.org/developers/testing/memorysanitizer ?
The build works out of the box for me on a fresh checkout. Could not reproduce the bug though, the command line from #22 exits silently with error code 0.

Thanks for the crash revision! I am able to reproduce the problem at the revision you gave. Curiously, the simulator has barely changed in that time.

> Jacob, did you follow http://dev.chromium.org/developers/testing/memorysanitizer ?

I'm using V8, not Chromium, so those instructions didn't seem to apply directly. I had to adapt them in places.

With GN, the build fails because I don't have build/instrumented_libraries (or something similar). With GYP, it never seems to be able to fetch prebuilt libraries so it tries to rebuild them. That's fine, except that I had to fix some paths in buildtools/third_party/libc++/libc++.gn. They're probably correct for the Chromium build, but they don't work for V8.

The MSAN problem appears to have been fixed by d6473f5 (#36968), which corrected a guard which protected a memory access. I've confirmed this by cherry-picking it onto the known-bad revision.

There are some potential signed-overflow problems in the simulator, but they are not to blame here. (I'll make a patch to fix them anyway.)

To be clear, those are V8 revisions.

Removing EditIssue view restrictions from ClusterFuzz filed bugs. If you believe that this issue should still be restricted, please reapply the label.

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