Created attachment 8881644 [details] Firefox-DOS.html User Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/58.0.3029.110 Safari/537.36 Steps to reproduce: Dynamically creating HTML elements IMG,FORM,DIV,P,A,H2,IFRAME,TABLE,TEXTAREA and assign very long string of junk chars to the "style.color" property results in Firefox browser crash (not tab). Actual results: Firefox crash, possible out of memory... no time to research yet. So I will check the security option below.
Group: firefox-core-security → core-security
Component: Untriaged → CSS Parsing and Computation
Product: Firefox → Core
Crash Signature: [@ OOM | large | mozalloc_abort | mozalloc_handle_oom | moz_xrealloc | GrowStuff ]
status-firefox54: --- → wontfix
status-firefox55: --- → affected
status-firefox56: --- → affected
status-firefox-esr52: --- → affected
Version: 53 Branch → unspecified
Thanks for the crash report, Ryan. It looks like we're trying to generate a very large CSS error message, and we crash safely in an OOM.
mozilla::dom::HTMLMediaElement::ReportLoadError() seems to also hit a similar crash signature.
Summary: Firefox Multiple Denial Of Service (for now) → OOM crash when creating CSS error message
Yea I figured it was OOM, this will be be fix etc? thanks...
Generally we prioritize OOM crashes based on how common they are. This one doesn't appear to be particularly common.
So not being common means which priority?
(In reply to hyp3rlinx from comment #6) > So not being common means which priority? It means low priority. Although...we limit CSS error messages to something short so they don't cause these sorts of problems, IIRC. Maybe we should be limiting load errors similarly?
status-firefox55: affected → wontfix
status-firefox56: affected → wontfix
status-firefox57: --- → wontfix
status-firefox58: --- → wontfix
Priority: P3 → P5
You need to log in before you can comment on or make changes to this bug.