FF crashes intermittently (but frequently) loading FTP protocol pages in stack overflow from recursion in nsCSSFrameConstructor::ConstructFramesFromItemList
Categories
(Core :: Layout, defect, P4)
Tracking
()
People
(Reporter: chaplain, Unassigned)
Details
(Keywords: crash, csectype-dos, testcase-wanted, Whiteboard: [sg:dos stack-exhaustion])
Crash Data
Attachments
(1 file)
49.21 KB,
text/plain
|
Details |
User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Firefox/78.0
Steps to reproduce:
0 - Start FF (I will typically have many tabs open)
1 - Create new tab
2 - Go to an anonymous FTP protocol site, specifically ftp://ftp.adobe.com/pub/adobe/
Can also be reproduced in an existing tab viewing a different page. I.e., execute 2 in any tab can reproduce.
Actual results:
Initially one gets the yellow "A web page is slowing down your browser. What would you like to do?" bar. Selecting "Wait" will lead to a recurrence of this bar. Selecting "Stop it" produces a crash page.
Occasionally it will load the page but it fails far far more often than succeeds.
I need to note three unusual side effects:
1 - If you view a different page (or pages) while waiting for this page to load, when this page crashes and you click "Restore This Tab", those other pages may be affected. Specifically those other pages may go back one page in their history. (Suggesting an exploitable inter-process security issue.)
2 - When this page crashes and one clicks "Restore This Tab", the tab does not attempt to restore the tab, it reverts to the previous page in the tab history (or an empty tab if this the FTP load is attempted from a new tab).
3 - If following a crash I re-enter the ftp address in the address bar INSTEAD of clicking "Restore This Tab", often times (but not always) the FTP directory will load.
Expected results:
A directory tree for the FTP location should have been displayed.
Comment 1•4 years ago
|
||
Can you go to about:crashes and copy a link from a crash report that is definitely related to these content process crashes?
Does this reproduce on a clean profile? If not, can you attach your about:support data (open about:support, click copy raw data to clipboard, paste at https://bugzilla.mozilla.org/attachment.cgi?bugid=1675355&action=enter as a file) ?
https://crash-stats.mozilla.org/report/index/fd5ae5df-b702-4a17-9fd7-0a7680201104
I've not tried a clean profile, but I will look that up and get back to you.
Comment 5•4 years ago
|
||
Some kind of script is changing something to do with the style system and is causing infinite recursion of sorts in the style system code, which causes a stack overflow. Mats, can you take a look?
Reporter, can you try if the problem reproduces with your add-ons disabled, and if not, bisect them (ie enable half, see if it crashes, if not, disable that half and enable the other half, then narrow it down further) ?
I expect the script that's running is one from your add-ons -- about:support suggests you don't have userChrome/userContent.css enabled, and the link from comment #0 points to an FTP directory listing, not an HTML file, and Firefox runs almost no script/style code of itself there ( https://searchfox.org/mozilla-central/rev/c938c7416c633639a5c8ce4412be586eefb48005/netwerk/streamconv/converters/nsIndexedToHTML.cpp#357 is the script we run).
Comment 6•4 years ago
|
||
Another question, could you go to https://profiler.firefox.com and take a profile while the slow script dialog appears?
I took my best guess at an add-on to disable. I got a winner on guess #2. I have been testing "Duck Duck Go Privacy Essentials." Upon disabling it, I've been unable to reproduce the problem.
Not sure how to report this issue to them, but I guess this makes my test unsuccessful.
(In reply to Neil from comment #7)
I took my best guess at an add-on to disable. I got a winner on guess #2. I have been testing "Duck Duck Go Privacy Essentials." Upon disabling it, I've been unable to reproduce the problem.
Not sure how to report this issue to them, but I guess this makes my test unsuccessful.
So to make things interesting, I re-enabled the DDG extension and have since been unable to reproduce the problem (on this machine). I have other running this profile. I will attempt to obtain the profiler info from one of them.
(In reply to Neil from comment #8)
(In reply to Neil from comment #7)
I took my best guess at an add-on to disable. I got a winner on guess #2. I have been testing "Duck Duck Go Privacy Essentials." Upon disabling it, I've been unable to reproduce the problem.
Not sure how to report this issue to them, but I guess this makes my test unsuccessful.
So to make things interesting, I re-enabled the DDG extension and have since been unable to reproduce the problem (on this machine). I have other running this profile. I will attempt to obtain the profiler info from one of them.
I've now reproduced the issue on the same machine by restarting FF with all of my original extensions enabled - I.e., DDG Privacy on. So to be clear I can eliminate the issue by stopping DDGPE and the issue remains clear even if I re-enable DDGPE. However if I start with DDGPE enabled, the issue resumes.
Further all attempts to run the profiler which this crash is occurring, have also crashed the profiler results page.
Reporter | ||
Comment 10•4 years ago
|
||
Successful ran profiler without crash. See: https://share.firefox.dev/3ezHs5K
Comment 11•4 years ago
|
||
The profile shows NoScript's softReload
function, and the FTP directory listing creating waaaaay too many items - it looks like there's some kind of infinite (or at least very long) recursion going on.
Your about:support lists you having NoScript 11.1.4 .
In https://github.com/hackademix/noscript/commit/9568584751a9fcf8c4ed9d3d00413e1066cf9070 (slated for release with 11.1.5rc1, judging by the github tags), it looks like NoScript is adding a fix/workaround for a similar problem - it's trying to detect directory listings and avoiding modification there.
Giorgio, have you maybe already investigated this and is there more you could share about what prompted that change and what is happening? I tried looking for corresponding issues on github but didn't see anything.
(to be clear, I think it is quite possible there is a gecko issue that also needs fixing, orthogonal to the noscript code change - but it's hard to be sure)
Comment 12•4 years ago
|
||
I've found an event listener reentrance bug which may be the cause of this issue and seems to be triggered on Firefox < 80 only (because it appears ftp:// and file:// document parsing is more streamlined in recent Geckos) when scripts are inserted early by other extensions.
Could you check if this is still reproducible on NoScript 1.1.1.5rc2?
Reporter | ||
Comment 13•4 years ago
|
||
(In reply to Giorgio Maone [:mao] from comment #12)
I've found an event listener reentrance bug which may be the cause of this issue and seems to be triggered on Firefox < 80 only (because it appears ftp:// and file:// document parsing is more streamlined in recent Geckos) when scripts are inserted early by other extensions.
Could you check if this is still reproducible on NoScript 1.1.1.5rc2?
I loaded 11.1.5rc2. No other changes beyond upgrading NoScript. I could no longer reproduce the problem.
Comment 14•4 years ago
•
|
||
(In reply to Neil from comment #0)
I need to note three unusual side effects:
1 - If you view a different page (or pages) while waiting for this page to load, when this page crashes and you click "Restore This Tab", those other pages may be affected. Specifically those other pages may go back one page in their history. (Suggesting an exploitable inter-process security issue.)
Firefox 78 (and release versions generally) do not separate each tab into its own process. The affected pages likely also belonged to the process that crashed. I'm fairly confident this particular problem isn't a security issue.
2 - When this page crashes and one clicks "Restore This Tab", the tab does not attempt to restore the tab, it reverts to the previous page in the tab history (or an empty tab if this the FTP load is attempted from a new tab).
This is because the load of the page never completed, so we didn't create a new session history entry, which we'd use to restore the tab. That we don't restore the last loading URL is a bug, but not a security issue. It's probably worth filing as a separate bug.
(In reply to Giorgio Maone [:mao] from comment #12)
I've found an event listener reentrance bug which may be the cause of this issue and seems to be triggered on Firefox < 80 only (because it appears ftp:// and file:// document parsing is more streamlined in recent Geckos) when scripts are inserted early by other extensions.
Could you check if this is still reproducible on NoScript 1.1.1.5rc2?
Thanks for the quick response, this is good to know. Do you have a reliable testcase? I tried with the FTP page from this bug and installing DDG privacy essentials as well as noscript, on a nightly build from the 78/79 merge day, and could not reproduce despite several attempts. Tested on macOS as this issue doesn't look like the platform should make any difference.
Comment 15•4 years ago
|
||
We should stop wasting our resources on the obsolete FTP protocol. The solution here is to disable the FTP protocol on all channels and then remove the code from the tree, just like Chrome is currently doing.
Comment 16•4 years ago
|
||
(In reply to Mats Palmgren (:mats) from comment #15)
We should stop wasting our resources on the obsolete FTP protocol. The solution here is to disable the FTP protocol on all channels and then remove the code from the tree, just like Chrome is currently doing.
AFAICT from the NoScript code and comments here, the same crash would likely be triggerable from file:///
or jar:file:
(ie chrome:
) index pages.
Comment 17•4 years ago
|
||
I'd be happy to analyze this crash if it can be triggered from a file:///
URL.
Updated•4 years ago
|
Comment 18•4 years ago
|
||
(In reply to :Gijs (he/him) from comment #14)
Do you have a reliable testcase?
-
Download NoScript 1.1.5 and unzip it locally.
-
Patch it this way:
diff a/content/syncFetchPolicy.js b/content/syncFetchPolicy.js
index 3b23138..ce3f411 100644
--- a/content/syncFetchPolicy.js
+++ b/content/syncFetchPolicy.js
@@ -84,7 +84,7 @@
return;
}
- if (DocumentFreezer.suppressedScripts === 0 && readyState === "loading") {
+ if (false && DocumentFreezer.suppressedScripts === 0 && readyState === "loading") {
// we don't care reloading, if no script has been suppressed
// and no readyState change has been fired yet
DocumentFreezer.unfreeze();
@@ -92,7 +92,7 @@
}
let softReload = ev => {
- removeEventListener("DOMContentLoaded", softReload, true);
+ //removeEventListener("DOMContentLoaded", softReload, true);
try {
debug("Soft reload", ev); // DEV_ONLY
try {
-
Install the unzipped patched folder as a temporary extension
-
When the yellow "A Web page is slowing down your browser. What would you like to do?" notification bar appears, press [Stop it].
-
Reload and watch the tab crashing.
Comment 19•3 years ago
|
||
The bug has a crash signature, thus the bug will be considered confirmed.
Description
•