bugzilla.mozilla.org will be intermittently unavailable on Saturday, March 24th, from 16:00 until 20:00 UTC.

Things may break if a chunk is located at the highest locations in memory




JavaScript: GC
4 years ago
2 years ago


(Reporter: lth, Unassigned)


Firefox Tracking Flags

(Not tracked)




4 years ago
If a chunk is located at the highest addresses in the address space then there is a high risk that it will cause instability, and it may be useful to guard against such a chunk allocation even in release builds.  It is not known whether there are any platforms where such an allocation is possible.  The issue exists only - to the extent it exists - on 32-bit platforms, since on 64-bit platforms the upper bits must all be zero.

Observe for starters that the nursery's currentEnd_ pointer is set to the address of the first byte beyond the available space in the current chunk of the nursery (this contradicts the documentation, which says the variable holds the address of the last byte of space in the chunk).  Since there is a little unavailable space in that chunk (the trailer), we always have currentEnd_>=position_, and currentEnd_ is never zero.

That being the case, even for small object sizes it is possible for position_+size to wrap around if the chunk is at the end of the address space.  Both the in-line allocator and the C++ allocator for the nursery use position_+size <= currentEnd_ as the test for overflow.  But this is correct only if the addition cannot wrap around.

Page zero is usually write-protected, so a wrapping-around allocation will be a crasher and not a security error.

There is a boundary case where size==2^32-position_, in this case position_+size==0 and the allocation test will succeed, but the allocated storage will overlap the chunk trailer plus whatever memory came before it.

The easiest fix would be to check, within the memory mapper, whether the mapped chunk is the high chunk, and if so just stash it away without using it, and then retry the allocation.

(It also seems to me that 64-bit platforms other than the __ia64__ could benefit from a guard against nonzero bits in the high 17, but that's by the way.)

Comment 1

4 years ago
It appears to be possible to have a 4GB virtual address space when running a 32-bit application on 64-bit Windows provided the application is linked with /LARGEADDRESSAWARE:


On 32-bit Windows, since Windows XP, applications are limited to 2GB (default) or 3GB (boot flags) memory.
You need to log in before you can comment on or make changes to this bug.