1850744 - Near-null deref at js/src/gc/Cell.h:135

Status: RESOLVED FIXED

(Core :: JavaScript Engine: JIT, defect, P3)

Description

[lukas.bernhard]

Steps to reproduce:

On git commit c3b462663f7d45d2d1fc91374a68856b484a9a29 the attached sample crashes with a near-null deref when invoked as obj-x86_64-pc-linux-gnu/dist/bin/js --baseline-warmup-threshold=10 --ion-warmup-threshold=100 --fuzzing-safe crash.js
Bisecting the issue points to commit 09feddcb4287 related to bug 1824051.

function main() {
    const v1 = [0, 0, 0, 0]; 
    for (let v2 = 0; v2 < 50; v2++) { } 
    const o5 = { 
        __proto__: Reflect,
        set a(a4) {
        },  
    };  
    const v7 = new Proxy(v1, o5);
    v7.shift();
}
for (let v20 = 0; v20 < 10; v20++) {
    main();
}

#0  js::gc::HeaderWord::getAtomic (this=0x48)
    at js/src/gc/Cell.h:135
#1  0x000055555780c3d5 in js::gc::HeaderWord::flags (this=0x48)
    at js/src/gc/Cell.h:151
#2  0x000055555780c315 in js::gc::Cell::flags (this=0x48)
    at js/src/gc/Cell.h:189
#3  0x000055555780c282 in js::gc::CellWithTenuredGCPointer<js::gc::Cell, js::Shape>::headerPtr (this=0x48) at js/src/gc/Cell.h:832
#4  0x000055555780c225 in JSObject::shape (this=0x48)
    at js/src/vm/JSObject.h:91
#5  0x000055555780c055 in JSObject::compartment (this=0x48)
    at js/src/vm/JSObject.h:143
#6  0x00005555589cfbd2 in js::jit::AssertValidObjectPtr (cx=0x7ffff662ee00, obj=0x48)
    at js/src/jit/VMFunctions.cpp:1262

Comment 1

[Jan de Mooij [:jandem]]

NI Doug based on bisection result.

Comment 2

[Matthew Gaudet (he/him) [:mgaudet]]

Forwarding a comment from l11d on Matrix: "if someone finds the time to look into bug 1850744 that would be quite nice; the fuzzers find corresponding crashes all the time and they don't de-duplicate well"

Comment 3

[Alex Thayer [:alexical] (she/her)]

I'll take a closer look today. I wasn't able to reproduce it on this machine but I may be able to reproduce it on another one. I'll start getting that set up.

Comment 4

[Matthew Gaudet (he/him) [:mgaudet]]

I was able to reproduce, though first pass at trying to get an RR recording didn't work so I stopped there. Let me know if you need help trying to reproduce and I can try to work harder on that.

Comment 5

[lukas.bernhard]

https://pernos.co/debug/jnKFF38T6ZVjRLp6cK5TGw/index.html

Comment 6

[Steve Fink [:sfink] [:s:]]

I poked at the Pernosco recording a little. It's crashing on a poison value created by js::Debug_SetValueRangeToCrashOnTouch that was written into freshly allocated slots_. (You can see where in the Notebook pane of the recording.)

In more detail: an object inits a getter/setter property, which causes the slots_ array to grow. Offset 0 is set to UndefinedValue(). The rest are poisoned. The crash happens when accessing the poisoned slots_[4]. The object at this point only has 1 slot.

I haven't really done any tracking of JIT code back to its generation in Pernosco, so I'll stop here. Hopefully this will mean something to someone familiar with the changed code.

Comment 7

[Alex Thayer [:alexical] (she/her)]

Attachment: Bug 1850744 - Actually use the result of EmitReadSlotGuard r?iain

So, I wasn't handling traps on the proto chain correctly. As far as I can tell
though this should generally just be resulting in us failing to perform
optimally, as we should usually just load garbage out of the handler object
and then fail in guardSpecificFunction. The only way this could deviate from
that that I can think of is us segfaulting trying to load a bad slot from the
object.

Comment 8

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/53ad753dd40b
Actually use the result of EmitReadSlotGuard r=iain

Comment 9

[Cosmin Sabou [:CosminS]]

https://hg.mozilla.org/mozilla-central/rev/53ad753dd40b