Closed
Bug 1353228
Opened 8 years ago
Closed 7 years ago
Crash in nsPresContext::IsRootContentDocument called from ScrollFrameHelper::IsAlwaysActive()
Categories
(Core :: Web Painting, defect, P2)
Tracking
()
RESOLVED
FIXED
mozilla59
People
(Reporter: jesup, Assigned: mattwoodrow)
References
Details
(4 keywords, Whiteboard: [sec-triage-backlog])
Crash Data
This bug was filed from the Socorro interface and is
report bp-a59c00c7-7876-423b-ad28-206dc2170403.
=============================================================
330 crashes in the last week, mostly with this stack (some old revs had bugs with different stacks that crashed here), UAF signature.
(There's also a recent (51) crash when called from PresShell::AssumeAllFramesVisible(); that may be a separate bug. There are at a number crashes there in the last month; two are UAFs and are listed as being from 51.0.1ESR(!), but UAFs there start as early as 50b5)
The current UAF stack sequence seems to start in 52b6, with crash
https://crash-stats.mozilla.com/report/index/81817372-ae33-4ccd-893a-537d42170330
or thereabouts.
Reporter | ||
Updated•8 years ago
|
status-firefox52:
--- → affected
status-firefox53:
--- → affected
status-firefox54:
--- → affected
status-firefox55:
--- → ?
status-firefox-esr45:
--- → unaffected
status-firefox-esr52:
--- → affected
Updated•8 years ago
|
Updated•8 years ago
|
Group: core-security → layout-core-security
Updated•8 years ago
|
Component: Layout → Layout: Web Painting
Comment 1•8 years ago
|
||
ScrollFrameHelper::Destroy() does Cancel() and null out mDisplayPortExpiryTimer, so the timer should not fire if the scroll frame is already destroyed.
But perhaps, during the process of tearing down the frame tree, something else accessed in ExpireDisplayPortOnAsyncScrollableAncestor() (like an ancestor frame) or downstack (like the pres context, pres shell, view manager, or root view) can be already destroyed by the time ScrollFrameHelper::Destroy() is called?
Comment 2•8 years ago
|
||
Yeah, it's probably something related to views, we have plenty of bugs filed on similar looking crashes.
Updated•8 years ago
|
Keywords: testcase-wanted
Comment 3•8 years ago
|
||
Sec-high triage: we need somebody to be assigned to investigate and fix this bug. Matt, can you help on that?
Flags: needinfo?(matt.woodrow)
Assignee | ||
Comment 4•8 years ago
|
||
This seems very similar to bug 1328129.
Flags: needinfo?(matt.woodrow)
Updated•8 years ago
|
Whiteboard: [sec-triage-backlog]
Reporter | ||
Comment 5•7 years ago
|
||
Ping - sec high with no action in 5 months..... #3 UAF on 57/58
The "similar" bug is also still happening, with no action in 5 months.
NI-ing several people because I'm not sure who should move this forward.
status-firefox56:
--- → affected
status-firefox57:
--- → affected
status-firefox58:
--- → affected
Flags: needinfo?(milan)
Flags: needinfo?(matt.woodrow)
Flags: needinfo?(bugs)
Flags: needinfo?(botond)
I imagine bug 1261175 is a different flavour of the same root problem.
Flags: needinfo?(milan)
See Also: → 1261175
Kats, this and bug 1261175 and such - some association with scrolling, but is that real, and lifetime related, or just because scrolling happens a lot?
Flags: needinfo?(bugmail)
Comment 8•7 years ago
|
||
I think it's mostly because scrolling (and in particular expiry of displayports in scrollframes) happens a bunch. I took a sample of the first 10 crashes sorted by buildid descending and only 2 of the 10 had the scrolling stuff in the stack. Extrapolating from that the bulk of the crashes are not tied to any scrolling code.
It does seem like the best path forward is (as mentioned a few times in bug 1261175) to get bug 984690 landed and exorcising the view stuff from the codebase.
Flags: needinfo?(bugmail)
Updated•7 years ago
|
Priority: -- → P2
Hi Matt:
I have assigned these security bugs to you to reassign them to appropriate developers in your team to investigate and fix them.
Thanks!
Wennie
Assignee: nobody → matt.woodrow
Updated•7 years ago
|
Flags: needinfo?(botond)
Reporter | ||
Updated•7 years ago
|
Flags: needinfo?(matt.woodrow)
Reporter | ||
Comment 10•7 years ago
|
||
re-NI to put it at the top of matt's stack
Flags: needinfo?(matt.woodrow)
Assignee | ||
Comment 11•7 years ago
|
||
Has this dropped in frequency since bug 1261175's assertion landed?
I can't find any crash reports with this stack in 58.
At a glance it looks like the same crash (pres shell return a dead view manager), so seems plausibly the same bug.
Flags: needinfo?(matt.woodrow) → needinfo?(rjesup)
Reporter | ||
Comment 12•7 years ago
|
||
I re-NI'd you because wennie assigned you to the bug without a NI (and you were already NI'd from 3 weeks ago).
None after 57b8 that I can see, and none in 58. https://crash-stats.mozilla.com/report/index/abd70fcb-23ee-43ac-af27-c51920171019 is an example of a 57b8 crash
There are a handful of 58a1 and 57bN crashes, called from dom::DOMIntersectionObserver::Update()
https://crash-stats.mozilla.com/report/index/48dfc13e-2b08-4dcf-b27c-222730171029
Flags: needinfo?(rjesup)
Comment 13•7 years ago
|
||
As of right now, I don't see any crash reports on 58 or 59 for this signature. I'm going to assert FIXED here, using 59 as the version tag. We'll hear about it soon enough if bug 1261175 doesn't fix this one.
Status: NEW → RESOLVED
Closed: 7 years ago
status-firefox59:
--- → fixed
Depends on: 1261175
Flags: needinfo?(bugs)
Resolution: --- → FIXED
Version: 49 Branch → 59 Branch
Updated•7 years ago
|
Comment 14•7 years ago
|
||
One crash in IsRootContentDocument in 58.0b16 yesterday: https://crash-stats.mozilla.com/report/index/a439d300-3198-4c9b-9592-672e10180116
This one doesn't seem to involve ScrollFrameHelper::IsAlwaysActive() though.
Updated•7 years ago
|
Group: layout-core-security → core-security-release
Updated•7 years ago
|
Updated•7 years ago
|
Target Milestone: --- → mozilla59
Updated•6 years ago
|
Group: core-security-release
You need to log in
before you can comment on or make changes to this bug.
Description
•