Open Bug 1197540 Opened 5 years ago Updated 8 months ago

crash in nsGlobalWindow::InnerSetNewDocument(JSContext*, nsIDocument*)

Categories

(Core :: DOM: Core & HTML, defect, P5)

Unspecified
All
defect

Tracking

()

Tracking Status
firefox47 --- wontfix
firefox48 --- wontfix
firefox-esr45 --- wontfix
firefox-esr52 --- affected
firefox57 --- affected
firefox58 --- affected
firefox59 --- ?

People

(Reporter: dveditz, Unassigned)

References

(Blocks 1 open bug)

Details

(4 keywords)

Crash Data

Attachments

(4 files, 2 obsolete files)

Attached file fx_crash_poc.html (unreduced) (obsolete) —
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[1].

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[2] 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.

[...]
Attached file ASAN output from reporter (obsolete) —
Flags: needinfo?(bzbarsky)
Flags: needinfo?(bzbarsky)
Crash Signature: [@ nsGlobalWindow::InnerSetNewDocument(JSContext*, nsIDocument*)] → [@ nsGlobalWindow::InnerSetNewDocument(JSContext*, nsIDocument*)] [@ nsGlobalWindow::InnerSetNewDocument]
Keywords: sec-other
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.
OS: Mac OS X → All
Attached file test_case.html
Attachment #8651433 - Attachment is obsolete: true
Attached file prefs.js
Attached file asan_log.txt
Here is an up to date ASan log collected while reducing wit m-c
BuildID=20170918093516
SourceStamp=ffe6cc09ccf38cca6f0e727837bbc6cb722d1e71
Attachment #8651434 - Attachment is obsolete: true
Flags: in-testsuite?
Attached file debug_log.txt
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?
Priority: P2 → P5
You need to log in before you can comment on or make changes to this bug.