Open Bug 1197540 Opened 5 years ago Updated 8 months ago
crash in ns
Global Window::Inner Set New Document(JSContext*, ns IDocument*)
Filip Palian mailed the security alias about a null deref crash in nsGlobalWindow::InnerSetNewDocument, which also appears in low volume on on crash-stats. He provided an unreduced fuzzing testcase that crashed ASAN builds for him. I didn't see a crash in a regular Nightly but I haven't gotten to try an ASAN build. From his mail: -------------- I believe there's a bug, which crashes the Firefox browser. From what I can tell the bug is 100% reproducible. In order to trigger the bug and crash the browser all one needs to do is to visit the URL with the PoC file. The PoC was tested against: - newest nightly build of Firefox 43.0a1 for Linux - ancient iceweasel-31.6.0esr but default on some distributions - some older and newest Firefox versions for Windows The initial bug analysis has been performed to determine the root cause of a defect. However it's difficult for a person like me, who is not fluent with the Firefox source code and architecture, to achieve this goal. Anyway. I hope that information gathered thus far will be helpful in further analysis. [...]
Crash Signature: [@ nsGlobalWindow::InnerSetNewDocument(JSContext*, nsIDocument*)] → [@ nsGlobalWindow::InnerSetNewDocument(JSContext*, nsIDocument*)] [@ nsGlobalWindow::InnerSetNewDocument]
Crash volume for signature 'nsGlobalWindow::InnerSetNewDocument': - nightly (version 50): 0 crash from 2016-06-06. - aurora (version 49): 0 crash from 2016-06-07. - beta (version 48): 1 crash from 2016-06-06. - release (version 47): 52 crashes from 2016-05-31. - esr (version 45): 15 crashes from 2016-04-07. Crash volume on the last weeks: Week N-1 Week N-2 Week N-3 Week N-4 Week N-5 Week N-6 Week N-7 - nightly 0 0 0 0 0 0 0 - aurora 0 0 0 0 0 0 0 - beta 0 0 0 0 0 0 0 - release 6 10 9 8 9 4 1 - esr 1 0 4 0 3 2 3 Affected platforms: Windows, Mac OS X
I have been seeing this while fuzzing lately. I have a reduced test case that does reproduce the issue thought it may take multiple attempts.
Here is an up to date ASan log collected while reducing wit m-c BuildID=20170918093516 SourceStamp=ffe6cc09ccf38cca6f0e727837bbc6cb722d1e71
Attachment #8651434 - Attachment is obsolete: true
Running on a debug build triggers: Hit MOZ_CRASH(Unhandlable OOM while clearing document dependent slots.) at /src/dom/base/nsGlobalWindow.cpp:14656
OK. So the basic problem is that this testcase triggers infinite recursion. Once that recursion limit is hit, operations like restoring the values of the document-dependent slots can fail. And we don't have a way to handle them failing and leaving the slots uninitialized, so we crash to stay safe...
I hit this just now in beta (57 b13) on macOS: https://crash-stats.mozilla.com/report/index/84a7e9a7-9816-41ae-a7f9-a39a70171102 . I had 5 tabs open in a fresh profile: twitter (not logged in), youtube, yahoo mail (not logged in), fox news, and cnn. The YouTube/CNN content process crashed. I opened these tabs and when I came back to the machine in a few hours, the tab crash thing was present.
Priority: -- → P2
Most of the crash signatures seem to be on MacOS. There are a few in ESR52 and in 58 on crash-stats. Should this be duped to 1405521 or vice versa?
You need to log in before you can comment on or make changes to this bug.