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

Status: RESOLVED WORKSFORME

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

Description

[Daniel Veditz [:dveditz]]

Attachment: fx_crash_poc.html (unreduced)

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.

[...]

Comment 1

[Daniel Veditz [:dveditz]]

Attachment: ASAN output from reporter

Comment 2

[BugBot [:suhaib / :marco]]

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

Comment 3

[Tyson Smith [:tsmith]]

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.

Comment 4

[Tyson Smith [:tsmith]]

Attachment: test_case.html

Comment 5

[Tyson Smith [:tsmith]]

Attachment: prefs.js

Comment 6

[Tyson Smith [:tsmith]]

Attachment: asan_log.txt

Here is an up to date ASan log collected while reducing wit m-c
BuildID=20170918093516
SourceStamp=ffe6cc09ccf38cca6f0e727837bbc6cb722d1e71

Comment 7

[Tyson Smith [:tsmith]]

Attachment: 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

Comment 8

[Boris Zbarsky [:bzbarsky]]

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...

Comment 9

[Andrew Overholt [:overholt]]

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.

Comment 10

[Liz Henry (:lizzard)]

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?

Comment 11

[Andrei Purice]

Following the reporter's steps I am able to confirm that the issues doesn't happen anymore on Windows 10x64 or MacOS 10.15 on any of the current versions of Firefox Nightly 87.0a1 (2021-02-04), beta 86.0b6 and release 85.0 or the latest asan builds for each system. No crashes encountered during the tests.

Closing this issue as Resolved > Worksforme.
Feel free to re-open or file a new bug if this issue reoccurs again.