Closed Bug 1453897 Opened 7 years ago Closed 7 years ago

Crash in nsCOMPtr<T>::nsCOMPtr<T> | nsRuleNode::nsRuleNode

Categories

(Core :: CSS Parsing and Computation, defect)

60 Branch
All
Windows
defect
Not set
critical

Tracking

()

RESOLVED FIXED
Tracking Status
firefox-esr52 --- unaffected
firefox59 --- unaffected
firefox60 - disabled
firefox61 --- fixed

People

(Reporter: philipp, Unassigned)

References

Details

(Keywords: crash, csectype-uaf, regression)

Crash Data

This bug was filed from the Socorro interface and is report bp-71071944-7dc5-43b0-80bc-a36550180412. ============================================================= Top 10 frames of crashing thread: 0 xul.dll nsCOMPtr<nsILoadContextInfo>::nsCOMPtr<nsILoadContextInfo> mfbt/RefPtr.h:112 1 xul.dll nsRuleNode::nsRuleNode layout/style/nsRuleNode.cpp:1730 2 xul.dll nsRuleNode::Transition layout/style/nsRuleNode.cpp:1814 3 xul.dll nsRuleWalker::DoForward layout/style/nsRuleWalker.h:32 4 xul.dll nsRuleWalker::Forward layout/style/nsRuleWalker.h:43 5 xul.dll nsHTMLCSSStyleSheet::ElementRulesMatching layout/style/nsHTMLCSSStyleSheet.cpp:79 6 xul.dll nsHTMLCSSStyleSheet::RulesMatching layout/style/nsHTMLCSSStyleSheet.cpp:66 7 xul.dll EnumRulesMatching<ElementRuleProcessorData> layout/style/nsStyleSet.cpp:780 8 xul.dll nsStyleSet::FileRules layout/style/nsStyleSet.cpp:1158 9 xul.dll nsStyleSet::ResolveStyleForInternal layout/style/nsStyleSet.cpp:1338 ============================================================= crashes with this signature are regressing in firefox 60 - frequently a uaf. there were a number of reports early in the 61.0a1 nightly cycle as well, but the last report we got from 61 was build 20180317220121, so something seems to have fixed or moved the signature.
There's no way this code crashes in FF60 since it's gone. In any case all that code is gone from trunk, so should we mark this WONTFIX?
WONTFIX = there issue is valid, but we're intentionally declining to take any patches to fix it. (e.g. because the cost/benefit isn't a good tradeoff, or something like that) WONTFIX is & should be used very rarely. In this case I think the correct resolution would be either WORKSFORME (in the sense that "the issue has gone away in latest builds"), or more directly, FIXED with a dependency on whatever bug removed the code.
(In reply to Emilio Cobos Álvarez [:emilio] from comment #1) > There's no way this code crashes in FF60 since it's gone. The crash report in comment 0 shows that it's in a build labeled "60.:0b11" -- are you sure this code is gone in Firefox 60? (Also, RE wontfix and such: I was talking about the bug resolution status, but it's a slightly different call for status flags, e.g. status- firefox60:[wontfix|unaffected|fixed] etc.)
Flags: needinfo?(emilio)
https://bugzilla.mozilla.org/show_bug.cgi?id=stylo-chrome was fixed in 60, so there should be nobody using the old style system in 60, unless they turned it on intentionally.
Status: NEW → RESOLVED
Closed: 7 years ago
Depends on: stylo-chrome
Flags: needinfo?(emilio)
Resolution: --- → FIXED
Daniel, let me know if you're fine with resolving this as FIXED depending on stylo-chrome, otherwise we can reopen / resolve as you think it's better :)
Gotcha - that makes sense. So this user must've flipped a pref, I suppose? (Seems like it'll be worth monitoring crash volume here in case there's reason to believe a lot of users have this configuration. But aside from that: FIXED-by-stylo-chrome seems reasonable. Thanks!)
updating status flags per emilio's comments
Group: layout-core-security → core-security-release
Group: core-security-release
You need to log in before you can comment on or make changes to this bug.