Closed Bug 926596 Opened 11 years ago Closed 11 years ago

Crash [@ js::BaseShape::lookupUnowned]

Categories

(Core :: JavaScript Engine, defect)

x86_64
Linux
defect
Not set
critical

Tracking

()

RESOLVED FIXED
mozilla27
Tracking Status
firefox24 --- disabled
firefox25 --- disabled
firefox26 --- disabled
firefox27 --- fixed
firefox-esr24 --- disabled
b2g18 --- disabled
b2g-v1.2 --- disabled

People

(Reporter: decoder, Assigned: shu)

Details

(Keywords: crash, testcase, Whiteboard: [qa-])

Crash Data

Attachments

(2 files)

The following testcase crashes on mozilla-central revision 211337f7fb83 (threadsafe build, run with --fuzzing-safe --thread-count=2 --ion-compile-try-catch --ion-eager --ion-eager --ion-regalloc=backtracking --ion-parallel-compile=on):


gczeal(4);
function mergeSorted(l1, l2) {
  var result = [];
  var i1 = 0, i2 = 0, j = 0;
    result["1\u000C-\u000C1"] = l1[i1++];
  return result;
}
var elts = [];
for (var i = 0; i < 2048; i++)
  elts[i] = true;
elts.scanPar(mergeSorted);
The crash is from an optimized build. In a debug build I get asserts like in bug, but shu mentioned that this is a different bug. Here's a crash trace:


Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0xf19fdb40 (LWP 12219)]
js::BaseShape::lookupUnowned (cx=<optimized out>, base=...) at js/src/vm/Shape.cpp:1454
1454        if (!table.initialized())
#0  js::BaseShape::lookupUnowned (cx=<optimized out>, base=...) at js/src/vm/Shape.cpp:1454
#1  0x081095b7 in GetOrLookupUnownedBaseShape<(js::ExecutionMode)1> (base=..., cx=0xf19fd1f0) at js/src/vm/Shape.cpp:566
#2  JSObject::addPropertyInternal<(js::ExecutionMode)1> (cx=0xf19fd1f0, obj=(JSObject * const) 0xf6f7a010 [object Array], id=-150913792, getter=0, setter=0, slot=16777215, attrs=1, flags=0, shortid=0, spp=0x0, allowDictionary=true) at js/src/vm/Shape.cpp:632
#3  0x0810a4ef in JSObject::putProperty<(js::ExecutionMode)1> (cx=0xf19fd1f0, obj=(JSObject * const) 0xf6f7a010 [object Array], id=-150913792, getter=0, setter=0, slot=16777215, attrs=1, flags=0, shortid=0) at js/src/vm/Shape.cpp:766
#4  0x0821c71e in DefinePropertyOrElement<(js::ExecutionMode)1> (setterIsStrict=false, callSetterAfterwards=true, value=$jsval(-nan(0xfff8200000000)), shortid=0, flags=0, attrs=1, setter=0x8176e00 <JS_StrictPropertyStub(JSContext*, JS::Handle<JSObject*>, JS::Handle<int>, bool, JS::MutableHandle<JS::Value>)>, getter=0x8176df0 <JS_PropertyStub(JSContext*, JS::Handle<JSObject*>, JS::Handle<int>, JS::MutableHandle<JS::Value>)>, id=-150913792, obj=(JSObject * const) 0xf6f7a010 [object Array], cx=0xf19fd1f0) at js/src/jsobj.cpp:3548
#5  js::baseops::SetPropertyHelper<(js::ExecutionMode)1> (cxArg=0xf19fd1f0, obj=(JSObject * const) 0xf6f7a010 [object Array], receiver=(JSObject * const) 0xf6f7a010 [object Array], id=-150913792, defineHow=0, vp=$jsval(-nan(0xfff8200000000)), strict=false) at js/src/jsobj.cpp:4866
#6  0x0836a96b in js::jit::SetPropertyParIC::update (slice=0xf19fd1f0, cacheIndex=0, obj=(JSObject * const) 0xf6f7a010 [object Array], value=$jsval(-nan(0xfff8200000000))) at js/src/jit/IonCaches.cpp:2896
#7  0xf72ae2e9 in ?? ()
eax     0x0     0
eip     0x8101939 <js::BaseShape::lookupUnowned(js::ThreadSafeContext*, js::StackBaseShape const&)+25>
=> 0x8101939 <js::BaseShape::lookupUnowned(js::ThreadSafeContext*, js::StackBaseShape const&)+25>:      mov    0xec(%eax),%eax


I've marked this s-s because I've seen various crashes with this signature, but varying crash addresses, so I assume it might be controllable.
And I again forgot to remove unnecessary options in comment 0: No options are required for this test.
Another one for the "how did this ever work" department.
Attachment #816852 - Flags: review?
Assignee: general → shu
Status: NEW → ASSIGNED
Attachment #816852 - Flags: review? → review?(nmatsakis)
Christian, this will always result in a NULL (or +offset from NULL) access. What sec rating should this have?
(In reply to Shu-yu Guo [:shu] from comment #5)
> Christian, this will always result in a NULL (or +offset from NULL) access.
> What sec rating should this have?

What is the offset limited by? I've seen an offset of 0x150 in one case. If the offset can be reasonably large, then this could be sec-high or critical. If it cannot grow to any useful amount, then it's probably not a security bug.
Attachment #816852 - Flags: review?(nmatsakis) → review+
fixed in mozilla-central https://hg.mozilla.org/mozilla-central/rev/da7c23b2d1c7
Status: ASSIGNED → RESOLVED
Closed: 11 years ago
Flags: in-testsuite?
Resolution: --- → FIXED
Target Milestone: --- → mozilla27
Keywords: verifyme
I discussed this with :shu on irc

Although some of the code existed before b2g18 branched, the code is ifdef'd out for everything but nightly builds. Marking b2g18 as disabled
Keywords: verifyme
Whiteboard: [qa-]
Group: core-security
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: