In the fast path we do "jsuint newlen = start + count;", but none of the callers ensure (at least at first glance) that start + count does not overflow. At the very least, if this is going to be useful to array_concat, this overflow needs to be handled by bailing to the slow path.

Any progress on a patch for this?

Thanks for the prod! I was wrong: this cannot overflow. The key is that the max size of a Dense Array is int32, not uint32. EnsureDense will always sparsify if we flow over this count, so we will never do this arithmetic if it would overflow. The slow path is more clearly protected against overflow.

Marking this as invalid. Let me know if something needs to be done to the tracking flags.

Just a little note regarding the newest release of Firefox 10 regarding the exploit mentioned here: http://packetstormsecurity.org/files/105745/Mozilla-Firefox-Integer-Overflow.html Unfortunately, the vulnerability still exists. I tested the exploit myself (with the following add-on installed: NoScript) and the browser was rendered inoperable within seconds of launching the HTML. I do not know which versions of Windows are affected, but this was tested on an XP Professional machine with SP3 installed.

I think you have the wrong bug? This is a bug I opened to track what I thought might be an integer overflow. It isn't, I'm just paranoid.

By "rendered inoperable", you mean you start getting slow script dialogs? That isn't a vulnerability, just a way to prevent the browser from doing useful work, and that's easy enough to do that it would debase the term "vulnerability" if you called all such instances vulnerabilities. I can't get the testcase there (purged of spraying code, the relevant parts typed into the squarefree.com JS shell)) to do anything but pop up slow script dialogs. That's exactly what it should do, because it's looping from a really high number down to 0 getting every array element, finding they're all holes and doing nothing, then iterating to the next element/hole. What am I missing?

Perhaps not a "vulnerability" per se, but still an issue none-the-less that's remained unresolved. To a "novice" user, most would continue to allow the script to load thereby causing the browser to be unresponsive; i.e "not responding" as indicated in the Task Manager. The following was discovered just seconds ago from performing another test of said HTML/JS.. Prior to loading HTML: 79,216K CPU: 2% load After loading HTML: 225,288K CPU: 99% load Error signature szAppName : firefox.exe szAppVer : 10.0.0.4411 szModName : hungapp szModVer : 0.0.0.0 offset : 00000000