Closed Bug 1305779 Opened 5 years ago Closed 5 years ago

Crash [@ js::NativeObject::setSlot] or [@ js::gc::ChunkBitmap::markIfUnmarked] with use-after-free involving Debugger

Categories

(Core :: JavaScript Engine, defect)

x86_64
Linux
defect
Not set
critical

Tracking

()

RESOLVED DUPLICATE of bug 1302432
Tracking Status
firefox-esr45 --- ?
firefox50 --- fixed
firefox51 --- fixed
firefox52 --- fixed
firefox53 --- fixed

People

(Reporter: decoder, Assigned: jimb)

References

Details

(5 keywords, Whiteboard: [jsbugmon:ignore])

Crash Data

Attachments

(2 files)

The following testcase crashes on mozilla-central revision 66a77b9bfe5d (build with --enable-posix-nspr-emulation --enable-valgrind --enable-gczeal --disable-tests --enable-debug --enable-optimize, run with --fuzzing-safe --thread-count=2 --ion-eager --baseline-eager --ion-offthread-compile=off):

See attachment.



Backtrace:

 received signal SIGSEGV, Segmentation fault.
js::NativeObject::setSlot (this=0x7ffff36d2060, slot=405, value=...) at js/src/vm/NativeObject.h:844
#0  js::NativeObject::setSlot (this=0x7ffff36d2060, slot=405, value=...) at js/src/vm/NativeObject.h:844
#1  0x0000000000ad3aee in js::NativeObject::setSlotWithType (overwriting=true, value=..., shape=<optimized out>, cx=0x7ffff695f000, this=<optimized out>) at js/src/vm/NativeObject-inl.h:281
#2  NativeSetExistingDataProperty (cx=0x7ffff695f000, obj=obj@entry=..., shape=shape@entry=..., v=..., result=..., receiver=...) at js/src/vm/NativeObject.cpp:2133
#3  0x0000000000aec672 in SetExistingProperty (result=..., shape=..., pobj=..., receiver=..., v=..., id=..., obj=..., cx=0x7ffff695f000) at js/src/vm/NativeObject.cpp:2355
#4  js::NativeSetProperty (cx=cx@entry=0x7ffff695f000, obj=..., obj@entry=..., id=id@entry=..., value=..., value@entry=..., receiver=..., receiver@entry=..., qualified=qualified@entry=js::Unqualified, result=...) at js/src/vm/NativeObject.cpp:2418
#5  0x0000000000b0e13c in js::SetNameOperation (cx=0x7ffff695f000, script=<optimized out>, pc=<optimized out>, env=..., val=...) at js/src/vm/Interpreter-inl.h:287
#6  0x0000000000e69938 in js::jit::DoSetPropFallback (cx=0x7ffff695f000, frame=0x7fffffffb028, stub_=<optimized out>, lhs=..., rhs=..., res=...) at js/src/jit/BaselineIC.cpp:4560
#7  0x00007ffff7e3d20a in ?? ()
[...]
#23 0x0000000000000000 in ?? ()
rax	0xfffe494949494949	-482370842441399
rbx	0x7ffff36d2060	140737277403232
rcx	0x9	9
rdx	0x0	0
rsi	0x195	405
rdi	0x7fffffffa950	140737488333136
rbp	0x7fffffffa990	140737488333200
rsp	0x7fffffffa950	140737488333136
r8	0x7fffffffabe0	140737488333792
r9	0x7ffff69e9018	140737330974744
r10	0x270	624
r11	0x7fffffffac40	140737488333888
r12	0x195	405
r13	0x7ffff693a000	140737330257920
r14	0x7fffffffaaf0	140737488333552
r15	0x7ffff36d2060	140737277403232
rip	0x7e03bc <js::NativeObject::setSlot(unsigned int, JS::Value const&)+300>
=> 0x7e03bc <js::NativeObject::setSlot(unsigned int, JS::Value const&)+300>:	cmp    0x10(%rax),%r13
   0x7e03c0 <js::NativeObject::setSlot(unsigned int, JS::Value const&)+304>:	je     0x7e02e6 <js::NativeObject::setSlot(unsigned int, JS::Value const&)+86>
Attached file Testcase
Whiteboard: [jsbugmon:update,bisect] → [jsbugmon:bisect]
JSBugMon: Cannot process bug: Unable to automatically reproduce, please track manually.
Whiteboard: [jsbugmon:bisect] → [jsbugmon:]
=== Treeherder Build Bisection Results by autoBisect ===

The "good" changeset has the timestamp "20160719105325" and the hash "1915421654bdff6c883df496ccd7ad42bc83300f".
The "bad" changeset has the timestamp "20160719105326" and the hash "c23ff1725f56734958eb2978040ab36f278a6063".

Likely regression window: https://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=1915421654bdff6c883df496ccd7ad42bc83300f&tochange=c23ff1725f56734958eb2978040ab36f278a6063

This crash is intermittent, but autoBisect seems to point to bug 1119537. Jon, is bug 1119537 a likely regressor?
Blocks: 1119537
Flags: needinfo?(jcoppeard)
Whiteboard: [jsbugmon:] → [jsbugmon:ignore]
It's more likely that is an existing issue that's exposed by the fact that we're decommitting memory sooner.  That said it's probably GC-related, e.g. a missing barrier or something.
Flags: needinfo?(jcoppeard)
UAF sounds scary. Would be good if we could get to the bottom of what's going on here and assess how far back the root problem actually goes. Jim, can you please help with that?
Flags: needinfo?(jimb)
Group: javascript-core-security
I can reproduce this crash under RR.
Assignee: nobody → jimb
Flags: needinfo?(jimb)
It might be too late for 50, if we have a fix that seems safe we can consider uplifting for 50.1.0
Flags: needinfo?(jimb)
This requires the debugger, so I'm lowering it to sec-high.
Keywords: sec-criticalsec-high
I've been trying to figure this one out. I've attached a slightly reduced test case. It reproduces reliably, under GDB, RR, and with no debugger, but minor changes to the script will cause it not to crash, so my guess is that it's sensitive to allocation and not timing.

The value being assigned to foo in the line `foo = arguments` points to a relocated object. That value originates in JIT-generated code, so I don't know how to trace that very well.
Flags: needinfo?(jimb)
This is looking like a dup of 1308346. Verifying that the patch there fixes the problem here.
This is a dup of bug 1302432; the patch from that bug fixes this. In that bug, Ritu said, "Crash fix, Aurora51+, Beta50+"
Status: NEW → RESOLVED
Closed: 5 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 1302432
There are some crash reports still with [@ js::NativeObject::setSlot ] with some of those reports marked as exploitable, mostly on ESR 52.  I filed bug 1356434 for the remaining crashes.
So probably don't unhide this bug...
Group: javascript-core-security
You need to log in before you can comment on or make changes to this bug.