The following testcase asserts on mozilla-central revision 261d6997d1d1 (run with --ion-eager): function TestCase(n, d, e, a) {}; function reportCompare() { var testcase = new TestCase("x", 0); } reportCompare(); TestCase = ParallelArray; gczeal(6); try { reportCompare(); } catch(exc1) {} reportCompare();

S-s because gczeal is involved.

JSBugMon: Bisection requested, result: autoBisect shows this is probably related to the following changeset: The first bad revision is: changeset: 126654:a92c968b29ae user: Sean Stangl date: Tue Feb 19 14:06:40 2013 -0800 summary: Bug 837312: IonMonkey: Inline a strict subset of known targets, r=sstangl,djvj This iteration took 130.607 seconds to run.

Sean, could this be a regression from your patch? Also ccing some parallel array people.

The inlining code incorrectly assumed if that if TI knew the native call was in fact the ParallelArray constructor, then it would have already observed the expected ParallelArray TypeObject in the return typeset.

I'm going to assume that could be bad.

Please remember to ask for sec-approval, as this affects Aurora. Thanks.

Comment on attachment 741549 [details] [diff] [review] fix + testcase [Security approval request comment] How easily could an exploit be constructed based on the patch? Seems difficult without the ability to trigger eager compilation. It would require a script that observes calling the native ParallelArray constructor but not monitoring its results somehow *immediately before trying to Ion-compile*, via patching like the attached test case. Do comments in the patch, the check-in comment, or tests included in the patch paint a bulls-eye on the security problem? Not sure, could just remove the check-in/test comments though. Which older supported branches are affected by this flaw? Aurora; ParallelArrays are ifdef'd off in beta and above. If not all supported branches, which bug introduced the flaw? See comments. Do you have backports for the affected branches? If not, how different, hard to create, and risky will they be? Not risky, as this is an unpublicized API that's only ifdef'd on for Nightly and Aurora. How likely is this patch to cause regressions; how much testing does it need? Unlikely to cause regressions.

Comment on attachment 741549 [details] [diff] [review] fix + testcase sec-approval+. Please check into M-C and nominate the patch for Aurora.

Comment on attachment 741549 [details] [diff] [review] fix + testcase [Approval Request Comment] Bug caused by (feature/regressing bug #): 858077 User impact if declined: Possible exploit. Testing completed (on m-c, etc.): waiting on m-c Risk to taking this patch (and alternatives if risky): low String or IDL/UUID changes made by this patch: https://hg.mozilla.org/integration/mozilla-inbound/rev/c1f983b78f16

JSBugMon: The testcase found in this bug no longer reproduces (tried revision 7f68735fc8da).

JSBugMon: This bug has been automatically verified fixed.