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)

59 Branch
x86
Windows 7
defect

Tracking

()

RESOLVED FIXED
mozilla59
Tracking Status
firefox-esr45 --- unaffected
firefox52 --- wontfix
firefox-esr52 --- fixed
firefox53 --- wontfix
firefox54 --- wontfix
firefox55 --- wontfix
firefox56 --- wontfix
firefox57 --- wontfix
firefox58 --- fixed
firefox59 --- fixed

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.
Group: core-security → layout-core-security
Component: Layout → Layout: Web Painting
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?
Yeah, it's probably something related to views, we have plenty of bugs filed on similar looking crashes.
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)
This seems very similar to bug 1328129.
Flags: needinfo?(matt.woodrow)
Whiteboard: [sec-triage-backlog]
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.
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)
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)
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
Flags: needinfo?(botond)
Flags: needinfo?(matt.woodrow)
re-NI to put it at the top of matt's stack
Flags: needinfo?(matt.woodrow)
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)
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)
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
Depends on: 1261175
Flags: needinfo?(bugs)
Resolution: --- → FIXED
Version: 49 Branch → 59 Branch
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.
Group: layout-core-security → core-security-release
Target Milestone: --- → mozilla59
Group: core-security-release
You need to log in before you can comment on or make changes to this bug.