Closed Bug 626631 (CVE-2011-0057) Opened 13 years ago Closed 13 years ago

WebWorker causes firefox to crash [@ js::PropertyTable::search(int, bool) ]

Categories

(Core :: JavaScript Engine, defect)

defect
Not set
critical

Tracking

()

RESOLVED FIXED
Tracking Status
blocking2.0 --- betaN+
blocking1.9.2 --- .14+
status1.9.2 --- .14-fixed
blocking1.9.1 --- .17+
status1.9.1 --- .17-fixed

People

(Reporter: dan.kozlowski, Assigned: luke)

References

()

Details

(4 keywords, Whiteboard: [sg:critical?][hardblocker][fixed-in-tracemonkey])

Crash Data

Attachments

(3 files)

User-Agent:       Mozilla/5.0 (X11; Linux x86_64; rv:2.0b10pre) Gecko/20110116 Firefox/4.0b10pre
Build Identifier: Mozilla/5.0 (X11; Linux x86_64; rv:2.0b10pre) Gecko/20110116 Firefox/4.0b10pre

Simple WebWorker causes Firefox to crash. Run the listed page with at least one worker thread. Firefox will crash 

Reproducible: Always

Steps to Reproduce:
1. Visit Web Page 
2. Start up at least one Worker thread 
3. wait 
Actual Results:  
Firefox crashes

Expected Results:  
Backround thread run and posts data to the UI thread
confirming with SM trunk
bp-476080c0-cb13-44f3-bc46-4f7482110118

0 	mozjs.dll 	js::PropertyTable::search 	js/src/jsscope.cpp:309
1 	mozjs.dll 	JSObject::nativeSearch 	js/src/jsscope.h:672
2 	mozjs.dll 	js_GetProperty 	js/src/jsobj.cpp:5354
3 	mozjs.dll 	js::mjit::ic::GetProp 	js/src/methodjit/PolyIC.cpp:1692
4 	mozjs.dll 	js::mjit::EnterMethodJIT 	js/src/methodjit/MethodJIT.cpp:748
5 	mozjs.dll 	CheckStackAndEnterMethodJIT 	js/src/methodjit/MethodJIT.cpp:774
6 	mozjs.dll 	js::mjit::JaegerShot 	js/src/methodjit/MethodJIT.cpp:791
7 	mozjs.dll 	js::RunScript 	js/src/jsinterp.cpp:654
8 	mozjs.dll 	js::Invoke 	js/src/jsinterp.cpp:737
9 	mozjs.dll 	js::ExternalInvoke 	js/src/jsinterp.cpp:858
10 	mozjs.dll 	JS_CallFunctionValue 	js/src/jsapi.cpp:5019
11 	xul.dll 	nsXPCWrappedJSClass::CallMethod 	js/src/xpconnect/src/xpcwrappedjsclass.cpp:1700
12 	xul.dll 	nsXPCWrappedJS::CallMethod 	js/src/xpconnect/src/xpcwrappedjs.cpp:588
13 	xul.dll 	PrepareAndDispatch 	xpcom/reflect/xptcall/src/md/win32/xptcstubs.cpp:114
14 	xul.dll 	SharedStub 	xpcom/reflect/xptcall/src/md/win32/xptcstubs.cpp:141
15 	xul.dll 	nsDOMWorkerMessageHandler::DispatchEvent 	dom/src/threads/nsDOMWorkerMessageHandler.cpp:329
16 	xul.dll 	nsDOMWorker::DispatchEvent 	dom/src/threads/nsDOMWorker.cpp:2613
17 	xul.dll 	nsDOMFireEventRunnable::Run 	dom/src/threads/nsDOMWorker.cpp:1312
18 	xul.dll 	nsThread::ProcessNextEvent 	xpcom/threads/nsThread.cpp:633
19 	xul.dll 	MessageLoop::DoDelayedWork 	ipc/chromium/src/base/message_loop.cc:462
20 	xul.dll 	NS_ProcessNextEvent_P 	objdir/mozilla/xpcom/build/nsThreadUtils.cpp:250
21 	xul.dll 	mozilla::ipc::MessagePump::Run 	ipc/glue/MessagePump.cpp:134
22 	xul.dll 	MessageLoop::RunInternal 	ipc/chromium/src/base/message_loop.cc:219
23 	xul.dll 	MessageLoop::RunHandler 	ipc/chromium/src/base/message_loop.cc:202
24 	xul.dll 	MessageLoop::Run 	ipc/chromium/src/base/message_loop.cc:176
25 	xul.dll 	nsBaseAppShell::Run 	widget/src/xpwidgets/nsBaseAppShell.cpp:192
26 	xul.dll 	nsAppShell::Run 	widget/src/windows/nsAppShell.cpp:258
27 	xul.dll 	nsAppStartup::Run 	toolkit/components/startup/src/nsAppStartup.cpp:217
28 	xul.dll 	XRE_main 	toolkit/xre/nsAppRunner.cpp:3699
29 	seamonkey.exe 	NS_internal_main 	suite/app/nsSuiteApp.cpp:103
30 	seamonkey.exe 	wmain 	toolkit/xre/nsWindowsWMain.cpp:128
31 	seamonkey.exe 	__tmainCRTStartup 	objdir/mozilla/memory/jemalloc/crtsrc/crtexe.c:591
Assignee: nobody → general
Severity: normal → critical
Status: UNCONFIRMED → NEW
Component: General → JavaScript Engine
Ever confirmed: true
Product: Firefox → Core
QA Contact: general → general
Summary: WebWorker causes firefox to crash → WebWorker causes firefox to crash [@ js::PropertyTable::search(int, bool) ]
Version: unspecified → Trunk
blocking2.0: --- → ?
Blocks: 595975
Whiteboard: hardblocker
Reproduced. This is a great test case thanks. The crash I saw looked kinda scary, so I will hide this until we know whats up here.
Group: core-security
blocking2.0: ? → betaN+
This crashes 3.6 as well, so bad and likely exploitable.
blocking1.9.2: --- → ?
same signature as 595975 and a few more bugs that are not marked security sensitive.  here is the full list.

https://bugzilla.mozilla.org/buglist.cgi?quicksearch=595975,602223,615492

its also ranked #18 in firefox 4.0b9 so we should hold on 2.0+BetaN hardblocker status.
Chris can you please hide any bugs with a test case that trigger a similar stack?
ok, hid the 3 bugs listed on comment 4.
Assignee: general → lw
I am able to repro a crash on TM tip with all jits disabled in js::Interpret:4192 with an object painted over with 0xdadadada.
Hm... Could it be something in the structured clone code then?
I just put printfs around the 'buffer.read' in nsDOMWorkerEvent::GetData and a printf in gc and the gc happens after the read finishes.  So it looks like somewhere in the XPConnect machinery.  Fortunately its a pretty tight window, so I can bisect further.
Whiteboard: hardblocker → [sg:critical?][hardblocker]
Oh wow, nsAutoJSValHolder is totally wrong and totally not rooting the jsval.
Runs for much longer with no crash.

(On the down side, although animation continues, once this sucker gets revved up, I can't navigate away, at least in my debug build...)
Attachment #505570 - Flags: review?(bent.mozilla)
Attachment #505570 - Flags: review+
Nice catch. We should provide better auto rooter classes for heap rooted jsvals from within the engine and remove the code XPConnect and dom defines.
Attachment #505570 - Flags: review?(bent.mozilla) → review+
blocking1.9.2: ? → .14+
Luke, if we can get a branch patch ready today we can make the next 3.6 update.
We're going to try to shoehorn this into 1.9.2.14 (and 1.9.1.17 if affected). We'd need this landed either today or tomorrow. Please ask for branch approval when a branch patch is ready. Thanks for the quick patch Luke!
http://hg.mozilla.org/tracemonkey/rev/a80b4c08c189

(In reply to comment #13)
> We should provide better auto rooter classes for heap rooted jsvals
> from within the engine and remove the code XPConnect and dom defines.

Yeah, avoid a lot of code duplication.  Also it should only cost a doubly-linked list insertion/removal, none of this hash table business.
Whiteboard: [sg:critical?][hardblocker] → [sg:critical?][hardblocker][fixed-in-tracemonkey]
blocking1.9.1: --- → .17+
The issue exists on 1.9.1.  The same patch applies to both.

Re-asking for review since I had to change the patch to use the old scary type-unsafe rooting APIs.
Attachment #505601 - Flags: review?(gal)
Attachment #505601 - Flags: approval1.9.2.14?
Attachment #505601 - Flags: approval1.9.1.17?
Keywords: crash, testcase
Attached file PoC (zipped)
Saving testcase for posterity/QA
Attachment #505601 - Flags: review?(gal) → review+
Attachment #505601 - Flags: approval1.9.2.14?
Attachment #505601 - Flags: approval1.9.2.14+
Attachment #505601 - Flags: approval1.9.1.17?
Attachment #505601 - Flags: approval1.9.1.17+
Status: NEW → RESOLVED
Closed: 13 years ago
Resolution: --- → FIXED
Verified fixed in 1.9.2 with Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.14) Gecko/20110121 Firefox/3.6.14 ( .NET CLR 3.5.30729) and webpage. Saw the crash in 1.9.2.13. 

Verified fixed in 1.9.1 with Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.17) Gecko/20110121 Firefox/3.5.17 ( .NET CLR 3.5.30729) and webpage. Saw the crash in 1.9.1.16.
I can also verify the fix is working. Great job on the fast response. 

BZ
Alias: CVE-2011-0057
dan, ping chofmann@mozilla.com if you are interested in a security bug bounty for your help on this bug.
Group: core-security
Crash Signature: [@ js::PropertyTable::search(int, bool) ]
No longer blocks: 595975
Blocks: 595975
rforbes-bugspam-for-setting-that-bounty-flag-20130719
Flags: sec-bounty+
You need to log in before you can comment on or make changes to this bug.