Bug 1223810 (CVE-2016-2828)

Crash when zooming out on a three.js demo

RESOLVED FIXED

Status

()

Core
Graphics
--
critical
RESOLVED FIXED
2 years ago
a month ago

People

(Reporter: jomo, Assigned: jgilbert)

Tracking

(5 keywords)

44 Branch
crash, csectype-uaf, regression, reproducible, sec-high
Points:
---

Firefox Tracking Flags

(firefox42 wontfix, firefox43 wontfix, firefox44 wontfix, firefox45 wontfix, firefox46 wontfix, firefox47+ fixed, firefox48+ fixed, firefox49 fix-optional, firefox50 wontfix, firefox-esr4547+ fixed)

Details

(Whiteboard: [gfx-noted][adv-main47+][adv-esr45.2+], crash signature)

Attachments

(1 attachment)

(Reporter)

Description

2 years ago
User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:44.0) Gecko/20100101 Firefox/44.0
Build ID: 20151103004217

Steps to reproduce:

1. Visit this three.js demo: http://mrdoob.neocities.org/001
2. Try zooming out 3 or 4 times


Actual results:

All tabs are 'crashed'.

Browser console shows:
LoginManagerContent:Couldn't parse origin for about:blank [LoginManagerContent.jsm:1178]

I'm not sure if that's before or after the crash, though.


Expected results:

Tabs shouldn't crash, it should just zoom out.
Do you have a crash report for this crash?  See about:crashes.
Flags: needinfo?(mozilla)
(Reporter)

Comment 2

2 years ago
https://crash-stats.mozilla.com/report/index/82450ef0-2cc4-465f-8493-24cec2151111

It might be worth pointing out that the whole page starts slowing down. You can see the cube spinning slower until it crashes.
Flags: needinfo?(mozilla)
That crash report doesn't have much to go on.  :(

I tried reproducing in a current nightly debug build on Mac, but I just got the "slower and slower" behavior, no crash.  That said, I expect this is a graphics issue, and the fact that the "slower and slower" behavior affects all applications, not just Firefox, indicates that we're hosing the GPU at least...
Component: General → Graphics
Flags: needinfo?(milan)
(Reporter)

Comment 4

2 years ago
Created attachment 8686095 [details]
Screenshot of Google Chrome providing more information

Indeed, this happens with Google Chrome as well. However, it only crashes the current tab and provides information about what went wrong (WebGL crashed)
How do you zoom out?
(Reporter)

Comment 6

2 years ago
Use the browser's zoom functions.
The page itself doesn't change (apart from possible Aliasing changes), but the canvas size grows, as the three.js creator points out: https://twitter.com/mrdoob/status/664497227637878784
> How do you zoom out?

Command + '-' on Mac, for example.

Comment 8

2 years ago
I can reproduce

More reproducible STR:
1. Set preferences 
   zoom.minPercent = 5
   toolkit.zoomManager.zoomValues = 0.05, .3,.5,.67,.8,.9,1,1.1,1.2,1.33,1.5,1.7,2,2.4,3
2. Restart
3. Open the site http://mrdoob.neocities.org/001
4. Zoom out ~5%

Actual Results:
Tab srashes bp-9298633c-3679-486d-bd1c-414782151112
Severity: normal → critical
Status: UNCONFIRMED → NEW
Crash Signature: [@ mozilla::gl::GLContext::MakeCurrent]
Ever confirmed: true
Keywords: crash, reproducible
Can you set environment variables MOZ_GL_DEBUG, MOZ_GL_DEBUG_ABORT_ON_ERROR to 1 and run the build from this try run (once it's done building) and try to reproduce?
https://treeherder.mozilla.org/#/jobs?repo=try&revision=1d1d7c4b3776
Flags: needinfo?(milan)
Sorry, make that this build instead: https://treeherder.mozilla.org/#/jobs?repo=try&revision=51132d3f624a
I suspect we're failing to create the texture for drawing into and not handling that properly. Sounds like an area nical is looking at.
Assignee: nobody → nical.bugzilla
Whiteboard: [gfx-noted]

Comment 12

2 years ago
looking at crash data this seems to be a regression in firefox 41.0 - the mozilla::gl::GLContext::MakeCurrent signature is 60% on android and 40% windows, and on #48 on release atm.

many of the crashes reports contain a GraphicsCriticalError field similar to the following: 
|[0][GFX1]: [D3D11] 2 CreateTexture2D failure Size(1680,939) Code: 0x8007000e|[1][GFX1]: [D3D11] 2 CreateTexture2D failure Size(1680,939) Code: 0x8007000e|[2][GFX1]: Failed 2 buffer db=0x00000000 dw=0x00000000 for 0, 79, 1680, 939

many user comments reference google maps in the reports.
status-firefox42: --- → affected
status-firefox43: --- → affected
status-firefox44: --- → affected
Keywords: regression
0x8007000e are out of memory messages...
Depends on: 1224199
Lots of these reports with this signature are crashing on a jemalloc-poisoned address indicating it's likely a use-after-free.
Group: gfx-core-security
status-firefox45: --- → affected
status-firefox46: --- → affected
status-firefox47: --- → affected
status-firefox48: --- → affected
status-firefox-esr45: --- → affected
Keywords: csectype-uaf, sec-high
(In reply to Daniel Veditz [:dveditz] from comment #14)
> Lots of these reports with this signature are crashing on a
> jemalloc-poisoned address indicating it's likely a use-after-free.

Yes. I don't think we can do anything about this without properly fixing bug 1224199.
To be clear, this bug is pretty much a dupe of bug 1224199. I am not marking it as such because its currently getting more attention than bug 1224199. To fix it we need to invert the ownership of GLScreenBuffer and GLContext, in order to be able to let textures have strong references to their GLContext (currently not possible because GLContext owns a ScreenBuffer which owns a SurfaceFactory, which owns textures, so it creates a cycle). That's a change that would be best operated (or at least vetted) by someone who owns the gl code (Jeff and Dan are needinfo'ed in bug 1224199).
Assignee: nical.bugzilla → nobody
sec-high and blocking/dupe of a crash bug 1224199.
Assignee: nobody → jgilbert
Flags: needinfo?(jgilbert)
Too late for a fix in 46, but we could still take a patch for 47 with sec-approval.
status-firefox46: affected → wontfix
tracking-firefox47: --- → +
tracking-firefox48: --- → +
Looks like there is a patch on bug 1224199, I'll comment there but keep tracking here.
This landed on central (bug 1224199 comment 22) and is awaiting uplift to 47.
(Assignee)

Comment 21

a year ago
(In reply to Milan Sreckovic [:milan] from comment #20)
> This landed on central (bug 1224199 comment 22) and is awaiting uplift to 47.

That was uplifted to 47.
We need to verify that this no longer repros, or re-evaluate.

Does this still crash for you on Nightly?
Flags: needinfo?(jgilbert) → needinfo?(mozilla)
(Reporter)

Comment 22

a year ago
Not crashing for me anymore using FirefoxDev 48.0a2 (2016-05-09).
Flags: needinfo?(mozilla)
(Assignee)

Comment 23

a year ago
Thanks!
status-firefox42: affected → wontfix
status-firefox43: affected → wontfix
status-firefox44: affected → wontfix
status-firefox45: affected → wontfix
status-firefox47: affected → fixed
status-firefox48: affected → fixed
This landed without sec-approval so it didn't get flagged for branches. We should have investigated whether to take this sec-high security bug on ESR45.
Flags: needinfo?(rkothari)
Flags: needinfo?(lhenry)
Whiteboard: [gfx-noted] → [gfx-noted][adv-main47+]
Alias: CVE-2016-2828
Well let's investigate it now. Looks like we did try to merge a patch (and it failed) in bug 1224199. 
Jeff can you request sec-approval if that's what should happen? I'll also comment in the other bug.
Flags: needinfo?(lhenry) → needinfo?(jgilbert)
tracking-firefox-esr45: --- → ?

Updated

a year ago
Flags: needinfo?(rkothari)
Fixed in bug 1224199 for esr45.2.0
status-firefox-esr45: affected → fixed
tracking-firefox-esr45: ? → 47+
(Assignee)

Comment 27

a year ago
We should be done here.
We'll do a better job with handling the sec- aspect in the future. This one ended up pear-shaped.
Status: NEW → RESOLVED
Last Resolved: a year ago
Flags: needinfo?(jgilbert)
Resolution: --- → FIXED
Whiteboard: [gfx-noted][adv-main47+] → [gfx-noted][adv-main47+][adv-esr45.2+]
Group: gfx-core-security → core-security-release
Crash volume for signature 'mozilla::gl::GLContext::MakeCurrent':
  - nightly (50): 356
  - aurora (49): 1

Affected platform: Windows
status-firefox49: --- → affected
status-firefox50: --- → affected
Can you have a look at the reports in crash-stats? There are still crashes on 49.0b1 for both fennec and Firefox.  We could file a new bug for those crashes if that seems best.
Flags: needinfo?(jgilbert)
See also https://bugzilla.mozilla.org/show_bug.cgi?id=1287444#c18, the crash has been fixed in 50, probably by bug 1286459, but I'm trying to confirm it with a reporter who was able to reproduce the crash.
For 49.0b6: 3 crashes for desktop, 27 for fennec.  
We are now heading into beta 9 later this week but could still take a patch if these remaining crashes are still sec-high, and if it seems worth the risk.
status-firefox49: affected → fix-optional
Group: core-security-release

Comment 32

5 months ago
Too late to fix in 50.1.0 release
status-firefox50: affected → wontfix
(Assignee)

Updated

a month ago
Flags: needinfo?(jgilbert)
You need to log in before you can comment on or make changes to this bug.