Crash in nsMenuPopupFrame::ShouldFollowAnchor

RESOLVED FIXED in Firefox -esr60

Status

()

defect
P1
critical
RESOLVED FIXED
2 years ago
10 days ago

People

(Reporter: philipp, Assigned: enndeakin)

Tracking

({crash, csectype-uaf, sec-high})

53 Branch
mozilla63
All
Windows
Points:
---
Bug Flags:
qe-verify -

Firefox Tracking Flags

(firefox-esr52 unaffected, firefox-esr6063+ fixed, firefox58 wontfix, firefox59 wontfix, firefox60 wontfix, firefox61 wontfix, firefox62 wontfix, firefox63 fixed)

Details

(Whiteboard: [post-critsmash-triage][adv-main63+][adv-esr60.3+], crash signature)

Attachments

(2 attachments)

This bug was filed from the Socorro interface and is
report bp-5231f334-613d-4a79-8695-930a60180224.
=============================================================

Top 10 frames of crashing thread:

0 xul.dll nsMenuPopupFrame::ShouldFollowAnchor layout/xul/nsMenuPopupFrame.cpp:2537
1 xul.dll nsMenuPopupFrame::ShouldFollowAnchor layout/xul/nsMenuPopupFrame.cpp:2560
2 xul.dll nsMenuChainItem::UpdateFollowAnchor layout/xul/nsXULPopupManager.cpp:120
3 xul.dll nsXULPopupManager::ShowPopupCallback layout/xul/nsXULPopupManager.cpp:975
4 xul.dll nsXULPopupManager::FirePopupShowingEvent layout/xul/nsXULPopupManager.cpp:1547
5 xul.dll nsXULPopupManager::ShowPopupAtScreen layout/xul/nsXULPopupManager.cpp:816
6 xul.dll nsXULPopupListener::LaunchPopup dom/xul/nsXULPopupListener.cpp:443
7 xul.dll nsXULPopupListener::HandleEvent dom/xul/nsXULPopupListener.cpp:219
8 xul.dll mozilla::EventListenerManager::HandleEventSubType dom/events/EventListenerManager.cpp:1118
9 xul.dll mozilla::EventListenerManager::HandleEventInternal dom/events/EventListenerManager.cpp:1293

=============================================================

these crashes on windows are apparently rising in volume with firefox 58 somewhat. windows 8.1 looks like it's overrepresented in crash stats.
since there are reports from firefox 53 but none from 52esr, perhaps the crash is related to bug 1109868?
Enn/:tn, any idea what's going on here? Is it possible the frame is gone or something?
Flags: needinfo?(tnikkel)
Flags: needinfo?(enndeakin)
Tracing though, the only thing I can see is that a call to nsContentUtils::NotifyInstalledMenuKeyboardListener can happen (from SetCaptureState) and that does a whole bunch of ime stuff that perhaps could destroy the frame, although I don't know for sure.

A possible quick fix is to just add another weakframe check just before the call to UpdateFollowAnchor at:

https://hg.mozilla.org/releases/mozilla-release/annotate/849c090094db/layout/xul/nsXULPopupManager.cpp#l975

That said, if that is the issue, it may have caused different crashes before 1109868 as well as the frame is accessed immediately afterwards again.
Flags: needinfo?(enndeakin)
Keywords: sec-high
Priority: -- → P1
(In reply to Neil Deakin from comment #2)
> A possible quick fix is to just add another weakframe check just before the
> call to UpdateFollowAnchor at:
> 
> https://hg.mozilla.org/releases/mozilla-release/annotate/849c090094db/layout/
> xul/nsXULPopupManager.cpp#l975
> 
> That said, if that is the issue, it may have caused different crashes before
> 1109868 as well as the frame is accessed immediately afterwards again.


I think that's worth trying out. WDYT?
Flags: needinfo?(enndeakin)
No harm in checking here.
Assignee: nobody → enndeakin
Status: NEW → ASSIGNED
Flags: needinfo?(enndeakin)
Attachment #9005155 - Flags: review?(tnikkel)
Flags: needinfo?(tnikkel)
Attachment #9005155 - Flags: review?(tnikkel) → review+
https://hg.mozilla.org/integration/mozilla-inbound/rev/be6a30c44b959056e51e970ebe99a03829df32b5
https://hg.mozilla.org/mozilla-central/rev/be6a30c44b95
Group: toolkit-core-security → core-security-release
Status: ASSIGNED → RESOLVED
Closed: Last year
Resolution: --- → FIXED
Target Milestone: --- → mozilla63
This is rated sec-high and affects more than trunk, so it shouldn't have landed without sec-approval.
https://wiki.mozilla.org/Security/Bug_Approval_Process

Please request it retroactively so we can figure out what we need to do for other branches.
Comment on attachment 9005155 [details] [diff] [review]
Check if the frame has been destroyed before calling UpdateFollowAnchor

[Security approval request comment]
> How easily could an exploit be constructed based on the patch?

Don't know what causes the crash. Happens in chrome-only code. Probably a tooltip or other chrome-specific popup UI getting deleted while it is being opened.


> Do comments in the patch, the check-in comment, or tests included in the patch paint a bulls-eye on the security problem?

This is a null-check.

> Which older supported branches are affected by this flaw?
> If not all supported branches, which bug introduced the flaw?

Could theoretically happen since bug 1109868.


> Do you have backports for the affected branches? If not, how different, hard to create, and risky will they be?

No risk.

> How likely is this patch to cause regressions; how much testing does it need?

No risk.
Flags: needinfo?(enndeakin)
Attachment #9005155 - Flags: sec-approval?
Well, I guess since we fixed it on trunk when it was 63, we just need to backport this to ESR60 for 60.3.

Can we get a patch made and nominated for ESR60, please?
Flags: needinfo?(enndeakin)
Attachment #9005155 - Flags: sec-approval? → sec-approval+
[Approval Request Comment]
If this is not a sec:{high,crit} bug, please state case for ESR consideration:
User impact if declined: crashes
Fix Landed on Version: 63
Risk to taking this patch (and alternatives if risky): none
String or UUID changes made by this patch: none

See https://wiki.mozilla.org/Release_Management/ESR_Landing_Process for more info.
Flags: needinfo?(enndeakin)
Attachment #9007230 - Flags: approval-mozilla-esr60?
Flags: qe-verify-
Whiteboard: [post-critsmash-triage]
Comment on attachment 9007230 [details] [diff] [review]
Check if the frame has been destroyed before calling UpdateFollowAnchor, ESR60

Fixes a sec-high, approved for ESR 60.3.
Attachment #9007230 - Flags: approval-mozilla-esr60? → approval-mozilla-esr60+
Whiteboard: [post-critsmash-triage] → [post-critsmash-triage][adv-main63+][adv-esr60.3+]
Group: core-security-release
You need to log in before you can comment on or make changes to this bug.