Closed
Bug 694872
Opened 13 years ago
Closed 13 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•13 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•13 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: 13 years ago
Resolution: --- → DUPLICATE
Comment 3•13 years ago
|
||
Moving tracking flags over to the dupe.
Updated•10 years ago
|
Group: core-security
You need to log in
before you can comment on or make changes to this bug.
Description
•