Crash [@ js::TypedObject::constructUnsized] with SIGFPE

RESOLVED DUPLICATE of bug 1092318

Status

()

Core
JavaScript Engine
--
critical
RESOLVED DUPLICATE of bug 1092318
4 years ago
4 years ago

People

(Reporter: decoder, Unassigned)

Tracking

(Blocks: 1 bug, {crash, csectype-dos, testcase})

Trunk
x86_64
Linux
crash, csectype-dos, testcase
Points:
---

Firefox Tracking Flags

(firefox34 disabled, firefox35 affected, firefox-esr31 disabled)

Details

(Whiteboard: [jsbugmon:update,bisect], crash signature)

(Reporter)

Description

4 years ago
The following testcase crashes on mozilla-central revision e58842c764dd (run with --no-threads --fuzzing-safe):


var AA = TypedObject.uint8.array((0)).array();
var aa = new AA(new ArrayBuffer);
(Reporter)

Comment 1

4 years ago
Crash trace:

Program received signal SIGFPE, Arithmetic exception.
0x00000000004c2154 in js::TypedObject::constructUnsized (cx=0x1950220, argc=1, vp=0x1a0c0c8) at js/src/builtin/TypedObject.cpp:2509
2509            int32_t maximumLength = bytesRemaining / elemSize;
#0  0x00000000004c2154 in js::TypedObject::constructUnsized (cx=0x1950220, argc=1, vp=0x1a0c0c8) at js/src/builtin/TypedObject.cpp:2509
#1  0x0000000000a4fa01 in js::CallJSNative (cx=0x1950220, native=0x4c1ab0 <js::TypedObject::constructUnsized(JSContext*, unsigned int, JS::Value*)>, args=...) at js/src/jscntxtinlines.h:231
#2  0x0000000000a50012 in js::CallJSNativeConstructor (cx=0x1950220, native=0x4c1ab0 <js::TypedObject::constructUnsized(JSContext*, unsigned int, JS::Value*)>, args=...) at js/src/jscntxtinlines.h:264
#3  0x0000000000a44ed4 in js::InvokeConstructor (cx=0x1950220, args=...) at js/src/vm/Interpreter.cpp:578
#4  0x0000000000a358e1 in Interpret (cx=0x1950220, state=...) at js/src/vm/Interpreter.cpp:2560
#5  0x0000000000a43eb8 in js::RunScript (cx=0x1950220, state=...) at js/src/vm/Interpreter.cpp:428
#6  0x0000000000a46b2a in ExecuteKernel (result=0x0, evalInFrame=..., thisv=..., scopeChainArg=..., script=..., cx=0x1950220, type=<optimized out>) at js/src/vm/Interpreter.cpp:636
#7  js::Execute (cx=0x1950220, script=..., scopeChainArg=..., rval=0x0) at js/src/vm/Interpreter.cpp:673
rbp     0xffffc710      140737488340752
rip     0x4c2154 <js::TypedObject::constructUnsized(JSContext*, unsigned int, JS::Value*)+1700>
=> 0x4c2154 <js::TypedObject::constructUnsized(JSContext*, unsigned int, JS::Value*)+1700>:     idivl  -0x120(%rbp)



Needinfo from Niko because it involes TypedObject.
status-firefox35: --- → affected
Flags: needinfo?(nmatsakis)
Whiteboard: [jsbugmon:update,bisect]
status-firefox34: --- → disabled
status-firefox-esr31: --- → disabled
unhiding on the theory this is an unexploitable divide-by-zero
Group: core-security
Keywords: csectype-dos
bhackett, do you think you will be able to investigate this?
Flags: needinfo?(nmatsakis) → needinfo?(bhackett1024)
What is the blame cset here?
The problem here is that uint8.array(0) creates a type with byte length zero, and then creating an array of these things can this and all sorts of other bugs related to taking the division/modulus of that zero element byte length.  How is this supposed to be resolved in the spec?  I don't see anything on the harmony wiki about this.  I guess we could (a) throw when creating types with byte length zero, (b) pad out the length of such types, or (c) handle the complexity of dealing with zero length types when manipulating typed object arrays.  I'm guessing the answer here is (c) but it would be nice to be sure before going through the work of auditing the typed object code for these bugs.
Flags: needinfo?(bhackett1024) → needinfo?(nmatsakis)
Hmm. I had previously assumed that we would permit zero-sized types, but we've actually never discussed it explicitly. I can ping dlomov and see what his opinion is. It certainly adds a lot of complexity. I believe we also permit structs with no fields?
Flags: needinfo?(nmatsakis)

Comment 7

4 years ago
Not allowing zero-sized types is significantly worse UI than artificially padding such types to make them have non-zero size, which is usually a quality-of-implementation issue.  Zero-sized types will be relatively common as a program is in development, while few people will care that the the allotted space is not zero.
After some discussion with Dmitry/Dave, we felt like we should just permit zero-sized types. We did not consider the option of having the size of such a type be 1 or something like that.
The crash in this testcase should be fixed by bug 1092318 --- the division here is computing the maximum length of an unsized array, and bug 1092318 removes unsized arrays.  I looked through the other uses of a typed object's byte size and didn't see anything problematic.
Status: NEW → RESOLVED
Last Resolved: 4 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 1092318
You need to log in before you can comment on or make changes to this bug.