The following testcase crashes on mozilla-central revision 1ed5a88cd4d0 (run with --fuzzing-safe --ion-eager): Object.prototype[(0)] = 3; var N = 1 << 16; var array = Array(50); for (var i = 0; i != N/2; ++i) array[i] = i;
Since approximately August 05, I am seeing random crashes on the heap on all fuzzers. Unfortunately, none of these reproduce cleanly, they reproduce in 1% of all runs and are very hard to reduce and long running. Fortunately, it seems that on the ASan builds, I've found the same bug, just that it reproduces quicker and more cleanly. This *could* be due to different memory layout/initialization that ASan chooses. The crash looks like this: Program received signal SIGSEGV, Segmentation fault. 0x00007ffff7e8e15a in ?? () (gdb) bt #0 0x00007ffff7e8e15a in ?? () #1 0x00007ffff7e81564 in ?? () #2 0x0000000000000183 in ?? () #3 0x00007ffff6855101 in ?? () #4 0x0000000000000000 in ?? () (gdb) x /i $pc => 0x7ffff7e8e15a: mov %edx,(%rbx,%rbx,8) (gdb) info reg rbx rbx 0x609a00000210 106214541230608 (gdb) info reg edx edx 0x641 1601 On the non-ASan slaves, the crashes looked the same, in particular the register pattern. Jandem mentioned that the register pattern here might be characteristic for the bug. Marking this at least sec-high for now.
Regression from bug 900890, which was backported to aurora and beta a few days ago.
status-firefox22: --- → unaffected
status-firefox23: --- → unaffected
status-firefox24: --- → affected
status-firefox25: --- → affected
status-firefox26: --- → affected
tracking-firefox24: --- → ?
tracking-firefox25: --- → ?
tracking-firefox26: --- → ?
Assignee: general → jdemooij
Status: NEW → ASSIGNED
Created attachment 791255 [details] [diff] [review] Patch One-liner.
Attachment #791255 - Flags: review?(nicolas.b.pierron)
Comment on attachment 791255 [details] [diff] [review] Patch > [Security approval request comment] > How easily could an exploit be constructed based on the patch? Not trivial, but it's doable for somebody who knows what he's doing. > Do comments in the patch, the check-in comment, or tests included > in the patch paint a bulls-eye on the security problem? No. > Which older supported branches are affected by this flaw? Bug 900890 was backported to aurora and beta a few days ago, so aurora and beta are affected too. > If not all supported branches, which bug introduced the flaw? Bug 900890. > Do you have backports for the affected branches? If not, how different, > hard to create, and risky will they be? Should apply to older branches, just a one-liner. > How likely is this patch to cause regressions; how much testing does it need? Unlikely, and it should only affect 64-bit.
Comment on attachment 791255 [details] [diff] [review] Patch sec-approval+ for trunk. Once it is there, it is approved for beta and aurora. Let's try to avoid shipping the problem behavior. Please get this in soon so it gets released in a few betas.
status-b2g18: --- → unaffected
status-firefox-esr17: --- → unaffected
tracking-firefox24: ? → +
tracking-firefox25: ? → +
tracking-firefox26: ? → +
Attachment #791255 - Flags: review?(nicolas.b.pierron) → review+
Status: ASSIGNED → RESOLVED
Last Resolved: 5 years ago
status-firefox26: affected → fixed
Resolution: --- → FIXED
Target Milestone: --- → mozilla26
status-firefox24: affected → fixed
status-firefox25: affected → fixed
You need to log in before you can comment on or make changes to this bug.