Closed
Bug 694872
Opened 15 years ago
Closed 15 years ago
Assertion failure: m_value and crash [@ JSC::MacroAssemblerCodePtr::dataLocation] due to invalid code pointer
Categories
(Core :: JavaScript Engine, defect)
Tracking
()
RESOLVED
DUPLICATE
of bug 694200
People
(Reporter: decoder, Assigned: dmandelin)
Details
(Keywords: assertion, crash, testcase, Whiteboard: [sg:critical?] js-triage-needed)
Crash Data
The following test crashes on mozilla-central revision 801b68a91a1c (options -m -n -a):
p = Proxy.create({
has: function() {
try {
new uneval.prototype;
} catch (__iterator__) {
actual = '' + send;
}
}
})
Object.prototype.__proto__ = p
n = [];
S-s because this is an invalid pointer assertion. During reduction, intermediate steps also showed glibc aborts like
*** glibc detected *** /srv/repos/mozilla-central/js/src/debug64/js: corrupted double-linked list: 0x00000000023c7350 ***
which might be exploitable.
Backtrace:
Program received signal SIGSEGV, Segmentation fault.
0x00000000006e9520 in JSC::MacroAssemblerCodePtr::dataLocation (this=0x7ffffff92850) at ../assembler/assembler/MacroAssemblerCodeRef.h:156
156 void* dataLocation() const { ASSERT_VALID_CODE_POINTER(m_value); return m_value; }
(gdb) bt
#0 0x00000000006e9520 in JSC::MacroAssemblerCodePtr::dataLocation (this=0x7ffffff92850) at ../assembler/assembler/MacroAssemblerCodeRef.h:156
#1 0x000000000077bbcf in JSC::CodeLocationCommon::dataLabelPtrAtOffset (this=0x7ffffff92850, offset=-3) at ../assembler/assembler/CodeLocation.h:176
#2 0x000000000077bc5c in JSC::MacroAssemblerX86_64::repatchCall (call=..., destination=...) at ../assembler/assembler/MacroAssemblerX86_64.h:583
#3 0x000000000077c3f5 in JSC::RepatchBuffer::relink (this=0x7ffffff92910, call=..., destination=...) at ../assembler/assembler/RepatchBuffer.h:95
#4 0x000000000077c4d1 in js::mjit::ic::Repatcher::relink (this=0x7ffffff92910, call=..., stub=...) at ../methodjit/ICRepatcher.h:76
#5 0x00000000007849b8 in js::mjit::ic::BaseIC::disable (this=0xbd9d30, cx=0xbd3890, reason=0x878b4e "error", stub=0x7833c8)
at /srv/repos/mozilla-central/js/src/methodjit/PolyIC.cpp:2337
#6 0x000000000078d006 in PICStubCompiler::disable (this=0x7ffffff929e0, cx=0xbd3890, reason=0x878b4e "error") at /srv/repos/mozilla-central/js/src/methodjit/PolyIC.cpp:184
#7 0x000000000078cfcf in PICStubCompiler::disable (this=0x7ffffff929e0, reason=0x878b4e "error") at /srv/repos/mozilla-central/js/src/methodjit/PolyIC.cpp:180
#8 0x0000000000783905 in js::mjit::ic::GetProp (f=..., pic=0xbd9d30) at /srv/repos/mozilla-central/js/src/methodjit/PolyIC.cpp:1992
#9 0x00000000006e772a in throwpoline_exit () at /srv/repos/mozilla-central/js/src/methodjit/MethodJIT.cpp:164
#10 0x00007ffff7f64480 in ?? ()
#11 0x0000000000000000 in ?? ()
Comment 1•15 years ago
|
||
Saw a tweet yesterday from .mario (@0x6D6172696F) that he was crashing in Proxy create so there's a good chance for independent discovery that this is a potential security problem.
dmandelin: please find an appropriate assignee for this one.
Assignee: general → dmandelin
tracking-firefox10:
--- → +
tracking-firefox8:
--- → +
tracking-firefox9:
--- → +
Comment 2•15 years ago
|
||
The stack indicates this is due to disabling the IC on an error path, which is fixed by bug 694200 (also a crash under BaseIC::disable). I don't know if this is the same issue as the tweet, but bug 694200 has only been fixed on nightly for a couple days.
Status: NEW → RESOLVED
Closed: 15 years ago
Resolution: --- → DUPLICATE
Comment 3•15 years ago
|
||
Moving tracking flags over to the dupe.
Updated•12 years ago
|
Group: core-security
You need to log in
before you can comment on or make changes to this bug.
Description
•