Assertion failure: nelements <= (2147483647), at js/src/jstypedarray.cpp:3224

RESOLVED DUPLICATE of bug 867329

Status

()

--
critical
RESOLVED DUPLICATE of bug 867329
6 years ago
5 years ago

People

(Reporter: decoder, Assigned: sfink)

Tracking

(Blocks: 1 bug, {assertion, testcase})

Trunk
x86_64
Linux
assertion, testcase
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [jsbugmon:])

(Reporter)

Description

6 years ago
The following testcase asserts on mozilla-central revision 801ba75ac563 (no options required):


deserialize(serialize(ArrayBuffer(0x7ffffffa)));
(Reporter)

Comment 1

6 years ago
An opt-build is throwing "InternalError: size and count too large" so it might be that the condition is handled after the assertion. Still marking s-s until properly investigated to make sure this is the case.
Whiteboard: [jsbugmon:update,bisect]
(Reporter)

Updated

6 years ago
Whiteboard: [jsbugmon:update,bisect] → [jsbugmon:update]
(Reporter)

Comment 2

6 years ago
JSBugMon: Bisection requested, result:
autoBisect shows this is probably related to the following changeset:

The first bad revision is:
changeset:   92092:7a601537cb88
user:        Tom Schuster
date:        Sat Jan 14 09:43:00 2012 -0800
summary:     Bug 711843 - Update JSAPI for typed arrays, remove uses of jstypedarray.h outside the engine [r=Waldo,bz,Ms2ger,bholley,bjacob,philikon,evilpie,bent,yourmama] [a=mfinkle thanks to gkw]

This iteration took 52.258 seconds to run.
(Reporter)

Comment 3

6 years ago
Tom, can you take a look at this and check if it's a security problem?
Flags: needinfo?(evilpies)
So what happens here is that we happily seralize an ArrayBuffer that is not going to fit into an Uint8Array (at least that's what we try to assert). I think this comes down to allowing the construction of pretty huge ArrayBuffers compared to eg. Int32Array. We should have a lower limit there. And an extra check for the result size of the structured cloning for good measure in serialize. We never actually construct the very huge Uint8Array, so we should be safe.
Flags: needinfo?(evilpies)
(Reporter)

Comment 5

6 years ago
Opening based on comment 4.
Group: core-security
See Also: → bug 748426
(Assignee)

Updated

6 years ago
Assignee: general → sphink
(Reporter)

Updated

6 years ago
Whiteboard: [jsbugmon:update] → [jsbugmon:]
(Reporter)

Comment 6

6 years ago
JSBugMon: Cannot process bug: Unknown exception (check manually)
(Reporter)

Updated

6 years ago
Whiteboard: [jsbugmon:] → [jsbugmon:update]
(Reporter)

Updated

5 years ago
Whiteboard: [jsbugmon:update] → [jsbugmon:update,ignore]
(Reporter)

Comment 7

5 years ago
JSBugMon: The testcase found in this bug no longer reproduces (tried revision b842d26dd5f0).

Comment 8

5 years ago
It's likely bug 867329 fixed this, but I don't have time to double-check.
(Reporter)

Comment 9

5 years ago
(In reply to Jeff Walden [:Waldo] (remove +bmo to email) from comment #8)
> It's likely bug 867329 fixed this, but I don't have time to double-check.

Thanks, double checking now =)
Whiteboard: [jsbugmon:update,ignore] → [jsbugmon:bisectfix]
(Reporter)

Updated

5 years ago
Whiteboard: [jsbugmon:bisectfix] → [jsbugmon:]
(Reporter)

Comment 10

5 years ago
JSBugMon: Fix Bisection requested, result:
autoBisect shows this is probably related to the following changeset:

The first good revision is:
changeset:   130528:06962a458da3
user:        Jeff Walden
date:        Tue Apr 30 18:15:15 2013 -0700
summary:     Bug 867329 - Make JS_NewUint8Array and friends accept any uint32_t as length and throw if the length is too big -- not assert when it's too big.  r=sfink

This iteration took 321.514 seconds to run.
(Reporter)

Comment 11

5 years ago
That sounds like a reasonable fix to me :)
Status: NEW → RESOLVED
Last Resolved: 5 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 867329
You need to log in before you can comment on or make changes to this bug.