On 1.9.2 and 1.9.1 branches the dense array capacity can grow beyond JSID_INT_MAX (2**32 - 1) as the capacity limit is set to 2**word_size/sizeof(jsval). Thus on these branches with 64 bit CPU, when js_MakeArraySlow loops over all elements, it may reach indexes that goes beyond JSID_INT_MAX. For such indexes JS_ValueToId convert them into strings. The latter could trigger the last-ditch GC. That GC will collect JSScopeProperty instances that are added to the just created scope since the scope is not reachable through any object leading to a GC hazard.
In practice this can only be exploitable if one can allocate more than 8GB array which requires very high end hardware and patience to wait for an exploit to fill the array before killing the browser.
On the trunk the array capacity limit is set to 2*32/sizeof(jsval) or 2*29 so JS_ValueToId from makeDenseArraySlow cannot allocate any GC things. Still the implementation for the bug 569422 need to be aware of this as the proposed changes there allocates shapes as GC things leading to a possibility of the last-ditch GC for any array.
Forgot to set security-sensitive flag when submitting, sorry about that.
Don't we limit array length to 2^32-1, per ECMA?
(In reply to comment #2)
> Don't we limit array length to 2^32-1, per ECMA?
Yes, but on 64 bit the bug happens before that and related to the possibility of having an array with length exceeding JSID_INT_MAX, 2**30 - 1.
when do you think you'll have a chance to fix this? I know you've got other bugs in the air?
(In reply to comment #4)
> when do you think you'll have a chance to fix this? I know you've got other
> bugs in the air?
The fix should be trivial and I will have a patch tomorrow.
The patch to fix is the one-liner from bug Bug 575024. How should I nominate it for branches given that that bug is not restricted but this one is?
We need a different patch for the 1.9.1 branch since the one in bug 575024 doesn't apply. Does the #define for MAX_DSLOTS_LENGTH32 from the 1.9.2 branch work on 1.9.1 (presumably with the extra -1 term), or is the fact that it's missing mean js objects have different limits on that branch?
the patch for bug 575024 was checked in on the 1.9.2 branch by Reed, this should be fixed there.
the patch for 191 from bug 575024 has landed (see bug 575024 comment 10), so this should fix the problem on 1.9.1.