Thread by @maxpl0it

@_manfp’s Firefox renderer bug is a beauty that takes advantage of an optimisation implemented just 3 months ago. Let’s break it down!

In JavaScript, you can get a list of property names of an object using Object.keys(o). A common pattern to count the number of properties an object has is to use Object.keys(o).length.

Now, this can actually end up being quite slow for large objects, since Object.keys(o) constructs a whole new array with the property names in it.

If we’re just interested in the length of this array and not the array itself, this means we’re spending considerable time constructing arrays when we don’t need to.

Thankfully, 3 months ago, Mozilla added a nice optimisation that means the pattern of Object.keys(o).length no longer creates this array, saving us from wasting a LOT of memory.
github.com/mozilla/gecko-…

So where’s the bug? In the Range Analysis part of the just-in-time compiler! The range that was given to the new MObjectKeysLength JIT node was between 0 and NativeObject::MAX_SLOTS_COUNT, which is (1 << 28) - 1.
However, the number of properties we can add is much larger.

Here is a test case that shows this behaviour. The returned value should never be larger than (1 << 28) - 1, which is 268435455. The trigger shows that we can in fact go larger than this, a value that is not taken into account by the range analysis.

This can lead to an incorrect elimination of a bounds check for an array access and therefore an out-of-bounds read and write primitive.
Definitely one of the neatest Firefox bugs I’ve seen in a while!