Crash in js_TryMethod/js_GetMethod with JIT / Memory corruption

RESOLVED DUPLICATE of bug 624421

Status

()

Core
JavaScript Engine
--
critical
RESOLVED DUPLICATE of bug 624421
8 years ago
7 years ago

People

(Reporter: decoder, Unassigned)

Tracking

(Blocks: 1 bug, {crash, testcase})

Trunk
x86
Linux
crash, testcase
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(blocking2.0 betaN+, status1.9.2 unaffected, status1.9.1 unaffected)

Details

(Whiteboard: [sg:dupe 624421][hardblocker])

Attachments

(1 attachment)

(Reporter)

Description

8 years ago
Created attachment 503780 [details]
Test case for shell (run without -j, contains options() call)

The attached test case crashes both on 32 and 64 bit, both in released 2.0 betas and tip. The crashes on 32 and 64 bit are distinct.

On 32 bit, I get a broken stack in gdb:

Program received signal SIGSEGV, Segmentation fault.
0x0826d814 in js::Interpret(JSContext*, JSStackFrame*, unsigned int, JSInterpMode) ()
(gdb) bt
#0  0x0826d814 in js::Interpret(JSContext*, JSStackFrame*, unsigned int, JSInterpMode) ()
#1  0xbfffeff4 in ?? ()
#2  0x08325390 in ?? ()
Backtrace stopped: previous frame inner to this frame (corrupt stack?)


On 64 bit, I get a call on a broken function pointer:

(gdb) bt
#0  0x0000000000000067 in ?? ()
#1  0x00000000004f28ca in js_GetMethod (cx=0xab6d90, obj=0xa37d00, id=..., getHow=2, vp=0x7fffffffbb10) at jsobj.cpp:5390
#2  0x00000000004f559d in js_TryMethod (cx=0xab6d90, obj=0xa37d00, atom=0x7ffff6901640, argc=0, argv=0x0, rval=0x7fffffffbb90) at jsobj.cpp:6253
#3  0x00000000004f47e3 in js::DefaultValue (cx=0xab6d90, obj=0xa37d00, hint=JSTYPE_STRING, vp=0x7fffffffbbe0) at jsobj.cpp:5908
#4  0x0000000000578b8d in js_ValueToString (cx=0xab6d90, arg=...) at jsstr.cpp:3663
#5  0x0000000000447659 in js::array_sort (cx=0xab6d90, argc=0, vp=0x7ffff6abf158) at jsarray.cpp:1897
#6  0x00000000004ce2f8 in js::CallJSNative (cx=0xab6d90, native=0x4471dd <js::array_sort(JSContext*, unsigned int, js::Value*)>, argc=0, vp=0x7ffff6abf158) at jscntxtinlines.h:692
#7  0x00000000006e3dcd in js::Interpret (cx=0xab6d90, entryFrame=0x7ffff6abf048, inlineCallCount=1, interpMode=JSINTERP_NORMAL) at jsinterp.cpp:4783
#8  0x00000000004ca2c1 in js::RunScript (cx=0xab6d90, script=0xaf9eb0, fp=0x7ffff6abf048) at jsinterp.cpp:657
#9  0x00000000004cb716 in js::Execute (cx=0xab6d90, chain=0x7ffff6903048, script=0xaf9eb0, prev=0x0, flags=0, result=0x0) at jsinterp.cpp:1023
#10 0x000000000042e092 in JS_ExecuteScript (cx=0xab6d90, obj=0x7ffff6903048, script=0xaf9eb0, rval=0x0) at jsapi.cpp:4882
#11 0x000000000040554b in Process (cx=0xab6d90, obj=0x7ffff6903048, filename=0x7fffffffddbd "min.js", forceTTY=0) at js.cpp:453
#12 0x0000000000406324 in ProcessArgs (cx=0xab6d90, obj=0x7ffff6903048, argv=0x7fffffffda90, argc=2) at js.cpp:870
#13 0x000000000040f958 in Shell (cx=0xab6d90, argc=2, argv=0x7fffffffda90, envp=0x7fffffffdaa8) at js.cpp:5444
#14 0x000000000040fb1e in main (argc=2, argv=0x7fffffffda90, envp=0x7fffffffdaa8) at js.cpp:5552
(gdb) f 1
#1  0x00000000004f28ca in js_GetMethod (cx=0xab6d90, obj=0xa37d00, id=..., getHow=2, vp=0x7fffffffbb10) at jsobj.cpp:5390
5390        return op(cx, obj, obj, id, vp);
(gdb) print op
$18 = (js::PropertyIdOp) 0x67
(gdb) print obj
$19 = (JSObject *) 0xa37d00
(gdb) print obj->getOps()
$20 = (const js::ObjectOps *) 0xa37dc0
(gdb) print obj->getOps()->getProperty
$21 = (JSBool (*)(JSContext *, JSObject *, JSObject *, jsid, js::Value *)) 0x67
(gdb) print &(obj->getOps()->getProperty)
$24 = (JSBool (**)(JSContext *, JSObject *, JSObject *, jsid, js::Value *)) 0xa37dd0
(gdb) x/16w 0xa37dd0
0xa37dd0 <_ZN8JSString15unitStringTableE+3312>: 103     0       0       0
0xa37de0 <_ZN8JSString15unitStringTableE+3328>: 20      0       10714608        0
0xa37df0 <_ZN8JSString15unitStringTableE+3344>: 104     0       0       0
0xa37e00 <_ZN8JSString15unitStringTableE+3360>: 20      0       10714640        0

Here on 64 bit, I first thought that some NULL pointer might be involved, but this doesn't seem the case, it rather looks like the getOps() is already pointing to somewhere where it shouldn't.

In any case, this seems like some serious memory corruption to me, locking :)
(Reporter)

Updated

8 years ago
Keywords: crash, testcase
blocking2.0: --- → ?
blocking2.0: ? → betaN+
Whiteboard: hardblocker
Thanks for the additional test case, I'm more confident about the approach in bug 624421 now, and convinced there's more potential than a null-deref.
Status: NEW → RESOLVED
Last Resolved: 8 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 624421
Can someone please CC me on bug 624421?  Thanks.
When bug 624421 is fixed we need to re-test this one to make sure it's really the same thing.
status1.9.1: --- → unaffected
status1.9.2: --- → unaffected
Depends on: 624421
Whiteboard: hardblocker → [sg:critical?][hardblocker]
It is. I dupe'd it in comment #1 having tested that the patch fixed it.
Whiteboard: [sg:critical?][hardblocker] → [sg:dupe 624421][hardblocker]
(Reporter)

Updated

7 years ago
Blocks: 676763
(Reporter)

Comment 6

7 years ago
Fixed for a long time and not affecting old branches, opening this.
Group: core-security
You need to log in before you can comment on or make changes to this bug.