Closed
Bug 1062265
Opened 10 years ago
Closed 10 years ago
Crash [@ js::TypedObject::constructUnsized] with SIGFPE
Categories
(Core :: JavaScript Engine, defect)
Tracking
()
RESOLVED
DUPLICATE
of bug 1092318
People
(Reporter: decoder, Unassigned)
Details
(Keywords: crash, csectype-dos, testcase, Whiteboard: [jsbugmon:update,bisect])
Crash Data
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•10 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.
Updated•10 years ago
|
status-firefox34:
--- → disabled
status-firefox-esr31:
--- → disabled
Comment 2•10 years ago
|
||
unhiding on the theory this is an unexploitable divide-by-zero
Group: core-security
Keywords: csectype-dos
Comment 3•10 years ago
|
||
bhackett, do you think you will be able to investigate this?
Flags: needinfo?(nmatsakis) → needinfo?(bhackett1024)
Comment 4•10 years ago
|
||
What is the blame cset here?
Comment 5•10 years ago
|
||
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)
Comment 6•10 years ago
|
||
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•10 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.
Comment 8•10 years ago
|
||
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.
Comment 9•10 years ago
|
||
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
Closed: 10 years ago
Resolution: --- → DUPLICATE
You need to log in
before you can comment on or make changes to this bug.
Description
•