1504452 - (CVE-2018-18493) heap-buffer-overflow write in add_line

Status: RESOLVED FIXED

(Core :: Graphics: Canvas2D, defect, P3)

Description

[Atte Kettunen]

Attachment: heap-buffer-overflow-addline-prepare-GrRenderTargetOpListonPrepare.html

Tested on:

OS: Ubuntu 18.04

Firefox:  Downloaded with fuzzfetch:

:$ fuzzfetch --target firefox --os Linux --asan --fuzzing
[2018-11-03 19:51:41] > Task ID: eKR8so7vRgyEkAmBz42SeA
[2018-11-03 19:51:41] > Rank: 1541238293
[2018-11-03 19:51:41] > Changeset: ef27c14b46bf58f710753ae6bb6d2c01a8c3631f
[2018-11-03 19:51:41] > Build ID: 20181103094453

Firefox executed with ffpuppet using prefs.js from: https://github.com/MozillaSecurity/fuzzdata/blob/master/settings/firefox/prefs-default.js

The issue doesn't reproduce without the prefs.js.

To reproduce, use system with at least 8GB of RAM. Original reproducer caused mozalloc_abort with 4GB RAM, I minimized the testcase on a machine with 8GB of RAM.

ASAN-trace:

==94392==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x7f2f4710c000 at pc 0x7f2f5b3ceb60 bp 0x7fffdcf23b70 sp 0x7fffdcf23b68
WRITE of size 4 at 0x7f2f4710c000 thread T0
    #0 0x7f2f5b3ceb5f in add_line /builds/worker/workspace/build/src/gfx/skia/skia/src/gpu/ops/GrAAHairLinePathRenderer.cpp:695:30
    #1 0x7f2f5b3ceb5f in (anonymous namespace)::AAHairlineOp::onPrepareDraws(GrMeshDrawOp::Target*) /builds/worker/workspace/build/src/gfx/skia/skia/src/gpu/ops/GrAAHairLinePathRenderer.cpp:989
    #2 0x7f2f5b60286c in prepare /builds/worker/workspace/build/src/gfx/skia/skia/src/gpu/ops/GrOp.h:158:49
    #3 0x7f2f5b60286c in GrRenderTargetOpList::onPrepare(GrOpFlushState*) /builds/worker/workspace/build/src/gfx/skia/skia/src/gpu/GrRenderTargetOpList.cpp:112
    #4 0x7f2f5b5ba407 in GrOpList::prepare(GrOpFlushState*) /builds/worker/workspace/build/src/gfx/skia/skia/src/gpu/GrOpList.cpp:88:11
    #5 0x7f2f5b597374 in GrDrawingManager::executeOpLists(int, int, GrOpFlushState*) /builds/worker/workspace/build/src/gfx/skia/skia/src/gpu/GrDrawingManager.cpp:386:17
    #6 0x7f2f5b57d07c in GrDrawingManager::flush(GrSurfaceProxy*, int, GrBackendSemaphore*) /builds/worker/workspace/build/src/gfx/skia/skia/src/gpu/GrDrawingManager.cpp:304:23
    #7 0x7f2f5b5877e4 in GrDrawingManager::prepareSurfaceForExternalIO(GrSurfaceProxy*, int, GrBackendSemaphore*) /builds/worker/workspace/build/src/gfx/skia/skia/src/gpu/GrDrawingManager.cpp:441:24
    #8 0x7f2f5b5fcb2e in GrRenderTargetContext::prepareForExternalIO(int, GrBackendSemaphore*) /builds/worker/workspace/build/src/gfx/skia/skia/src/gpu/GrRenderTargetContext.cpp:1408:36
    #9 0x7f2f51916dbd in mozilla::layers::PersistentBufferProviderBasic::ReturnDrawTarget(already_AddRefed<mozilla::gfx::DrawTarget>) /builds/worker/workspace/build/src/gfx/layers/PersistentBufferProvider.cpp:50:9
    #10 0x7f2f55f61dd2 in mozilla::dom::CanvasRenderingContext2D::ReturnTarget(bool) /builds/worker/workspace/build/src/dom/canvas/CanvasRenderingContext2D.cpp:1949:22
    #11 0x7f2f55f6694c in mozilla::dom::CanvasRenderingContext2D::OnStableState() /builds/worker/workspace/build/src/dom/canvas/CanvasRenderingContext2D.cpp:1550:3
    #12 0x7f2f5606538b in applyImpl<mozilla::dom::CanvasRenderingContext2D, void (mozilla::dom::CanvasRenderingContext2D::*)()> /builds/worker/workspace/build/src/obj-firefox/dist/include/nsThreadUtils.h:1191:12
    #13 0x7f2f5606538b in apply<mozilla::dom::CanvasRenderingContext2D, void (mozilla::dom::CanvasRenderingContext2D::*)()> /builds/worker/workspace/build/src/obj-firefox/dist/include/nsThreadUtils.h:1197
    #14 0x7f2f5606538b in mozilla::detail::RunnableMethodImpl<mozilla::dom::CanvasRenderingContext2D*, void (mozilla::dom::CanvasRenderingContext2D::*)(), true, (mozilla::RunnableKind)0>::Run() /builds/worker/workspace/build/src/obj-firefox/dist/include/nsThreadUtils.h:1242
    #15 0x7f2f4e78fa67 in mozilla::CycleCollectedJSContext::ProcessStableStateQueue() /builds/worker/workspace/build/src/xpcom/base/CycleCollectedJSContext.cpp:366:12
    #16 0x7f2f4e792822 in mozilla::CycleCollectedJSContext::AfterProcessTask(unsigned int) /builds/worker/workspace/build/src/xpcom/base/CycleCollectedJSContext.cpp:431:3
    #17 0x7f2f50c266e5 in XPCJSContext::AfterProcessTask(unsigned int) /builds/worker/workspace/build/src/js/xpconnect/src/XPCJSContext.cpp:1288:30
    #18 0x7f2f4e9d8adf in nsThread::ProcessNextEvent(bool, bool*) /builds/worker/workspace/build/src/xpcom/threads/nsThread.cpp:1302:24
    #19 0x7f2f4e9e091d in NS_ProcessNextEvent(nsIThread*, bool) /builds/worker/workspace/build/src/xpcom/threads/nsThreadUtils.cpp:530:10
    #20 0x7f2f4fc46eff in mozilla::ipc::MessagePump::Run(base::MessagePump::Delegate*) /builds/worker/workspace/build/src/ipc/glue/MessagePump.cpp:97:21
    #21 0x7f2f4fb4325e in RunInternal /builds/worker/workspace/build/src/ipc/chromium/src/base/message_loop.cc:325:10
    #22 0x7f2f4fb4325e in RunHandler /builds/worker/workspace/build/src/ipc/chromium/src/base/message_loop.cc:318
    #23 0x7f2f4fb4325e in MessageLoop::Run() /builds/worker/workspace/build/src/ipc/chromium/src/base/message_loop.cc:298
    #24 0x7f2f58ab94d3 in nsBaseAppShell::Run() /builds/worker/workspace/build/src/widget/nsBaseAppShell.cpp:158:27
    #25 0x7f2f5cee1000 in nsAppStartup::Run() /builds/worker/workspace/build/src/toolkit/components/startup/nsAppStartup.cpp:290:30
    #26 0x7f2f5d1afa2e in XREMain::XRE_mainRun() /builds/worker/workspace/build/src/toolkit/xre/nsAppRunner.cpp:4784:22
    #27 0x7f2f5d1b2209 in XREMain::XRE_main(int, char**, mozilla::BootstrapConfig const&) /builds/worker/workspace/build/src/toolkit/xre/nsAppRunner.cpp:4929:8
    #28 0x7f2f5d1b3ce3 in XRE_main(int, char**, mozilla::BootstrapConfig const&) /builds/worker/workspace/build/src/toolkit/xre/nsAppRunner.cpp:5021:21
    #29 0x56184ee2167c in do_main /builds/worker/workspace/build/src/browser/app/nsBrowserApp.cpp:237:22
    #30 0x56184ee2167c in main /builds/worker/workspace/build/src/browser/app/nsBrowserApp.cpp:329
    #31 0x7f2f71aafb96 in __libc_start_main /build/glibc-OTsEL5/glibc-2.27/csu/../csu/libc-start.c:310
    #32 0x56184ed46eec in _start (/dev/shm/firefox/firefox+0x2deec)

0x7f2f4710c000 is located 6144 bytes to the left of 208584-byte region [0x7f2f4710d800,0x7f2f471406c8)
allocated by thread T0 here:
    #0 0x56184edef1b2 in realloc /builds/worker/workspace/moz-toolchain/src/llvm/projects/compiler-rt/lib/asan/asan_malloc_linux.cc:165:3
    #1 0x56184ee2299d in moz_xrealloc /builds/worker/workspace/build/src/memory/mozalloc/mozalloc.cpp:93:20
    #2 0x7f2f5bcb57fd in makeSpace /builds/worker/workspace/build/src/gfx/skia/skia/include/private/SkPathRef.h:472:46
    #3 0x7f2f5bcb57fd in SkPathRef::growForVerb(int, float) /builds/worker/workspace/build/src/gfx/skia/skia/src/core/SkPathRef.cpp:677
    #4 0x7f2f5bc8a24c in growForVerb /builds/worker/workspace/build/src/gfx/skia/skia/include/private/SkPathRef.h:77:30
    #5 0x7f2f5bc8a24c in SkPath::moveTo(float, float) /builds/worker/workspace/build/src/gfx/skia/skia/src/core/SkPath.cpp:777
    #6 0x7f2f5454f847 in MoveTo /builds/worker/workspace/build/src/obj-firefox/dist/include/mozilla/dom/CanvasRenderingContext2D.h:320:21
    #7 0x7f2f5454f847 in mozilla::dom::CanvasRenderingContext2D_Binding::moveTo(JSContext*, JS::Handle<JSObject*>, mozilla::dom::CanvasRenderingContext2D*, JSJitMethodCallArgs const&) /builds/worker/workspace/build/src/obj-firefox/dom/bindings/CanvasRenderingContext2DBinding.cpp:4915
    #8 0x379d8f364c74  (<unknown module>)
    #9 0x379d8ef8a4e1  (<unknown module>)

SUMMARY: AddressSanitizer: heap-buffer-overflow /builds/worker/workspace/build/src/gfx/skia/skia/src/gpu/ops/GrAAHairLinePathRenderer.cpp:695:30 in add_line
Shadow bytes around the buggy address:
  0x0fe668e197b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x0fe668e197c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x0fe668e197d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x0fe668e197e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x0fe668e197f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
=>0x0fe668e19800:[fa]fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0fe668e19810: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0fe668e19820: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0fe668e19830: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0fe668e19840: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0fe668e19850: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
Shadow byte legend (one shadow byte represents 8 application bytes):
  Addressable:           00
  Partially addressable: 01 02 03 04 05 06 07 
  Heap left redzone:       fa
  Freed heap region:       fd
  Stack left redzone:      f1
  Stack mid redzone:       f2
  Stack right redzone:     f3
  Stack after return:      f5
  Stack use after scope:   f8
  Global redzone:          f9
  Global init order:       f6
  Poisoned by user:        f7
  Container overflow:      fc
  Array cookie:            ac
  Intra object redzone:    bb
  ASan internal:           fe
  Left alloca redzone:     ca
  Right alloca redzone:    cb
  Shadow gap:              cc
==94392==ABORTING

Comment 1

[Daniel Veditz [:dveditz]]

We just landed a big Skia upgrade (bug 1502152). Can you reproduce this in a build before Halloween?

Comment 2

[Atte Kettunen]

Yes and no.

I downloaded a build from last monday:

[2018-11-05 23:34:11] Identified task: https://index.taskcluster.net/v1/task/gecko.v2.mozilla-central.pushdate.2018.10.29.20181029041625.firefox.linux64-fuzzing-asan-opt
[2018-11-05 23:34:11] > Task ID: PKRnffnyR32I8AUwQ-IQ3g
[2018-11-05 23:34:11] > Rank: 1540786585
[2018-11-05 23:34:11] > Changeset: d2e24bdf0648f3b79616518d64c425b79f7069a8
[2018-11-05 23:34:11] > Build ID: 20181029041625

ASAN doesn't report heap-buffer-overflow, but instead I get a non-null SEGV write.

==58649==ERROR: AddressSanitizer: SEGV on unknown address 0x7f0013be7000 (pc 0x7f0027dbcfee bp 0x7ffc3ae7ce90 sp 0x7ffc3ae7b480 T0)
==58649==The signal is caused by a WRITE memory access.
    #0 0x7f0027dbcfed in add_line /builds/worker/workspace/build/src/gfx/skia/skia/src/gpu/ops/GrAAHairLinePathRenderer.cpp
    #1 0x7f0027dbcfed in (anonymous namespace)::AAHairlineOp::onPrepareDraws(GrMeshDrawOp::Target*) /builds/worker/workspace/build/src/gfx/skia/skia/src/gpu/ops/GrAAHairLinePathRenderer.cpp:977
    #2 0x7f0027f818e1 in prepare /builds/worker/workspace/build/src/gfx/skia/skia/src/gpu/ops/GrOp.h:148:49
    #3 0x7f0027f818e1 in GrRenderTargetOpList::onPrepare(GrOpFlushState*) /builds/worker/workspace/build/src/gfx/skia/skia/src/gpu/GrRenderTargetOpList.cpp:88
    #4 0x7f0027f34207 in GrOpList::prepare(GrOpFlushState*) /builds/worker/workspace/build/src/gfx/skia/skia/src/gpu/GrOpList.cpp:84:11
    #5 0x7f0027f1511c in GrDrawingManager::executeOpLists(int, int, GrOpFlushState*) /builds/worker/workspace/build/src/gfx/skia/skia/src/gpu/GrDrawingManager.cpp:276:22
    #6 0x7f0027f13e7e in GrDrawingManager::internalFlush(GrSurfaceProxy*, GrResourceCache::FlushType, int, GrBackendSemaphore*) /builds/worker/workspace/build/src/gfx/skia/skia/src/gpu/GrDrawingManager.cpp:224:23
    #7 0x7f0027f0585b in flush /builds/worker/workspace/build/src/gfx/skia/skia/src/gpu/GrDrawingManager.h:99:22
    #8 0x7f0027f0585b in GrDrawingManager::prepareSurfaceForExternalIO(GrSurfaceProxy*, int, GrBackendSemaphore*) /builds/worker/workspace/build/src/gfx/skia/skia/src/gpu/GrDrawingManager.cpp:335

Other than the change from heap-buffer-overflow to SEGV, the stack trace is the same, so my guess is that it is the same issue, but the write hits outside of the buffer redzone. Didn't investigate any further.

Comment 3

[Lee Salzman [:lsalzman]]

Attachment: fix GrGLGpu buffer offset calculations

The only overflow I can see happening here in Skia's code was in the buffer offset calculations.

However, it seems that the Linux drivers of varying forms have their own internal bugs, depending on driver, hardware, and driver version, that can lead to potential issues like the above.

Once I fixed the issue this patch addresses, the binary Nvidia drivers were happily running. The open-source Intel drivers will otherwise just call explicitly abort, but nothing exploitable.

Whereas it seems like what the reporter might be experiencing is that somewhere in the driver's internal size calculation when BufferData or MapBuffer is called, it is overflowing and not properly giving the requested size. But if that is the case, and this patch does not fix it, then I don't know there is much we can do about that.

However, the good news is that accelerated Canvas2D is only actually used on 60 ESR on Mac. All other platforms we have accelerated Canvas2D disabled by default as of bug 1468801. If necessary, it might be worth just disabling that on 60 ESR as well.

Comment 4

[Lee Salzman [:lsalzman]]

Filed upstream security report https://bugs.chromium.org/p/skia/issues/detail?id=8530

Comment 5

[Atte Kettunen]

That buffer offset calculation explains how the issue type AddressSanitizer detects can change.

My fuzzer that caught this issue was running in Docker container, using what ever GPU Xvfb has in default install. Not sure if/how I can check the "GPU" Firefox uses in there.

I used VMware VM to minimize the reproducing file. According to Firefox about:support the "GPU" the VM is using is:

GPU #1
Active	Yes
Description	VMware, Inc. -- SVGA3D; build: RELEASE;  LLVM;
Vendor ID	VMware, Inc.
Device ID	SVGA3D; build: RELEASE;  LLVM;
Driver Version	3.0 Mesa 18.0.5

Currently I don't have any machines that have native Linux, so I can't test any other configuration.

Comment 6

[Lee Salzman [:lsalzman]]

Comment on attachment 9023164 [details] [diff] [review]
fix GrGLGpu buffer offset calculations

[Security Approval Request]

How easily could an exploit be constructed based on the patch?: The behavior of the bug is driver dependent, and currently we only have accelerated Canvas2D on 60 ESR + Mac, so it seems unlikely this could be easily exploited.

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

Which older supported branches are affected by this flaw?: 60 ESR + Mac

If not all supported branches, which bug introduced the flaw?: None

Do you have backports for the affected branches?: Yes

If not, how different, hard to create, and risky will they be?: 

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

Comment 7

[Lee Salzman [:lsalzman]]

Attachment: fix GrGLGpu buffer offset calculations (60 ESR)

Just a straight backport to 60 ESR...

Comment 8

[Al Billings [:abillings - ex-MoCo]]

sec-approval+ for nightly. Release management should approve for ESR60.

Comment 9

[Lee Salzman [:lsalzman]]

Comment on attachment 9023321 [details] [diff] [review]
fix GrGLGpu buffer offset calculations (60 ESR)

[Beta/Release Uplift Approval Request]

Feature/Bug causing the regression: Bug 1444506

User impact if declined: Potential heap overreads and overwrites that can be triggered from JS canvas2d.

Is this code covered by automated tests?: Yes

Has the fix been verified in Nightly?: No

Needs manual test from QE?: No

If yes, steps to reproduce: 

List of other uplifts needed: None

Risk to taking this patch: Low

Why is the change risky/not risky? (and alternatives if risky): Just does some offset math at 64 bits like it should have been doing instead of doing it with 32 bits of precision.

String changes made/needed:

Comment 10

[Sebastian Hengst [:aryx] (needinfo me if it's about an intermittent or backout)]

https://hg.mozilla.org/integration/mozilla-inbound/rev/5a43a256230ed6905945642bf5a9d7b81e4e6927
https://hg.mozilla.org/mozilla-central/rev/5a43a256230e

Comment 11

[Julien Cristau [:jcristau] (back April 22)]

Slightly confused here because the patch is flagged for beta uplift but says "60 ESR".

Comment 12

[Ryan VanderMeulen [:RyanVM]]

Comment on attachment 9023321 [details] [diff] [review]
fix GrGLGpu buffer offset calculations (60 ESR)

This only affects ESR60 since that's the only branch where this feature remains enabled by default. Approved for 60.4.0esr.

Comment 13

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/releases/mozilla-esr60/rev/1cf7d80355d5

Comment 14

[Lee Salzman [:lsalzman]]

(In reply to Ryan VanderMeulen [:RyanVM] from comment #12)
> Comment on attachment 9023321 [details] [diff] [review]
> fix GrGLGpu buffer offset calculations (60 ESR)
> 
> This only affects ESR60 since that's the only branch where this feature
> remains enabled by default. Approved for 60.4.0esr.

Oops. Meant to request esr60 approval. Accidentally ticked beta approval by mistake.

Comment 15

[Oana Botisan, Desktop QA]

Can you please provide me with some steps to reproduce and verify the fix.

Until this point I tried to download the build from taskcluster (2018-11-03) and open it with a profile that has the modified prefs. When I open the attached html, there was no crash.

The second method I tried was using fuzzfetch, but I am not sure that I used it correctly, because I couldn't open the builds. The folders were downloaded, but for some reason the browser didn't open.

Thank you.

Comment 16

[Atte Kettunen]

Using Ubuntu 18.04 in a VMWare virtual machine.

Download the build with fuzzfetch:

:~$ fuzzfetch --target firefox --os Linux --asan --fuzzing --build ef27c14b46bf58f710753ae6bb6d2c01a8c3631f -o /run/shm/
[2018-11-21 17:26:41] Identified task: https://index.taskcluster.net/v1/task/gecko.v2.mozilla-central.revision.ef27c14b46bf58f710753ae6bb6d2c01a8c3631f.firefox.linux64-fuzzing-asan-opt
[2018-11-21 17:26:41] > Task ID: eKR8so7vRgyEkAmBz42SeA
[2018-11-21 17:26:41] > Rank: 1541238293
[2018-11-21 17:26:41] > Changeset: ef27c14b46bf58f710753ae6bb6d2c01a8c3631f
[2018-11-21 17:26:41] > Build ID: 20181103094453
[2018-11-21 17:26:41] > Downloading: https://queue.taskcluster.net/v1/task/eKR8so7vRgyEkAmBz42SeA/artifacts/public/build/target.tar.bz2 (290.88MB total)
[2018-11-21 17:27:11] .. still downloading (44.7%, 4.33MB/s)
[2018-11-21 17:27:41] .. still downloading (73.2%, 3.55MB/s)
[2018-11-21 17:28:00] .. downloaded (3.66MB/s)
[2018-11-21 17:28:00] .. extracting

Fuzzfetch will extract the downloaded revision to /run/shm/m-c-20181103094453-fuzzing-asan-opt/

Download the repro-file and pref-default.js to ~/Downloads.

Then use ffpuppet to launch Firefox with specific profile file:(https://github.com/MozillaSecurity/ffpuppet/)

:~$ ffpuppet -d -u ~/Downloads/heap-buffer-overflow-addline-prepare-GrRenderTargetOpListonPrepare.html -p ~/Downloads/prefs-default.js /run/shm/m-c-20181103094453-fuzzing-asan-opt/firefox
[2018-11-21 17:40:15] Running Firefox (pid: 86798)...
[2018-11-21 17:40:24] Shutting down...
[2018-11-21 17:40:25] Firefox process closed
[2018-11-21 17:40:25] Dumping browser log...

===
=== Dumping 'log_ffp_asan_86795.log.86798.txt' (5.38KB)
===
=================================================================
==86798==ERROR: AddressSanitizer: SEGV on unknown address 0x7f1df6c0e000 (pc 0x7f1e0ae3fb5d bp 0x7fff71dc9090 sp 0x7fff71dc73e0 T0)
==86798==The signal is caused by a WRITE memory access.
    #0 0x7f1e0ae3fb5c in add_line /builds/worker/workspace/build/src/gfx/skia/skia/src/gpu/ops/GrAAHairLinePathRenderer.cpp
    #1 0x7f1e0ae3fb5c in (anonymous namespace)::AAHairlineOp::onPrepareDraws(GrMeshDrawOp::Target*) /builds/worker/workspace/build/src/gfx/skia/skia/src/gpu/ops/GrAAHairLinePathRenderer.cpp:989
    #2 0x7f1e0b07586c in prepare /builds/worker/workspace/build/src/gfx/skia/skia/src/gpu/ops/GrOp.h:158:49
    #3 0x7f1e0b07586c in GrRenderTargetOpList::onPrepare(GrOpFlushState*) /builds/worker/workspace/build/src/gfx/skia/skia/src/gpu/GrRenderTargetOpList.cpp:112
    #4 0x7f1e0b02d407 in GrOpList::prepare(GrOpFlushState*) /builds/worker/workspace/build/src/gfx/skia/skia/src/gpu/GrOpList.cpp:88:11
    #5 0x7f1e0b00a374 in GrDrawingManager::executeOpLists(int, int, GrOpFlushState*) /builds/worker/workspace/build/src/gfx/skia/skia/src/gpu/GrDrawingManager.cpp:386:17
...

Comment 17

[Oana Botisan, Desktop QA]

I tried with a vm too and with the steps from comment 16, but I didn't manage to reproduce the issue or to make the Firefox build to open.
Can you please check to see if the issue is reproducing on Firefox 65 and on ESR 60?
Thank you.

Comment 18

[Atte Kettunen]

You couldn't start up Firefox? Maybe you are missing some dependencies? I haven't had any problems like that. Can you install and run Firefox from the OS repositories?

I can test builds that fuzzfetch can get. If you can give me some identifier, build num, or REV, to use with Firefox 65 I can try with that.

I downloaded and tested with current ESR 60 build from fuzzfetch.

:~$ fuzzfetch --target firefox --os Linux --asan --fuzzing --esr -o /run/shm/firefox-repro
[2018-11-23 17:30:21] Latest available build is older than 1 day: 20181120134235
[2018-11-23 17:30:23] Identified task: https://index.taskcluster.net/v1/task/gecko.v2.mozilla-esr60.latest.firefox.linux64-fuzzing-asan-opt
[2018-11-23 17:30:23] > Task ID: b14eDTRvSz-5LLny8yxHew
[2018-11-23 17:30:23] > Rank: 1542721355
[2018-11-23 17:30:23] > Changeset: 8d50553b267a8c38d2fd1c0a38c14bd1b32e0fdb
[2018-11-23 17:30:23] > Build ID: 20181120134235
[2018-11-23 17:30:24] > Downloading: https://queue.taskcluster.net/v1/task/b14eDTRvSz-5LLny8yxHew/artifacts/public/build/target.tar.bz2 (225.64MB total)
[2018-11-23 17:30:49] .. downloaded (8.43MB/s)
[2018-11-23 17:30:49] .. extracting

:~$ ffpuppet -d -u ~/Downloads/repro.html -p ~/Downloads/prefs-default.js /run/shm/firefox-repro/m-e-20181120134235-fuzzing-asan-opt/firefox
[2018-11-23 17:33:34] Running Firefox (pid: 5538)...
[2018-11-23 17:33:59] Shutting down...
[2018-11-23 17:34:01] Firefox process closed
[2018-11-23 17:34:01] Dumping browser log...

===
=== Dumping 'log_ffp_asan_5519.log.5538.txt' (8.18KB)
===
=================================================================
==5538==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x7efc5183e003 at pc 0x7efca4a6fc83 bp 0x7ffe7155daf0 sp 0x7ffe7155dae8
WRITE of size 8 at 0x7efc5183e003 thread T0
    #0 0x7efca4a6fc82 in add_line /builds/worker/workspace/build/src/gfx/skia/skia/src/gpu/ops/GrAAHairLinePathRenderer.cpp:685:25
    #1 0x7efca4a6fc82 in (anonymous namespace)::AAHairlineOp::onPrepareDraws(GrMeshDrawOp::Target*) /builds/worker/workspace/build/src/gfx/skia/skia/src/gpu/ops/GrAAHairLinePathRenderer.cpp:977
    #2 0x7efca4c29b12 in prepare /builds/worker/workspace/build/src/gfx/skia/skia/src/gpu/ops/GrOp.h:148:49
    #3 0x7efca4c29b12 in GrRenderTargetOpList::onPrepare(GrOpFlushState*) /builds/worker/workspace/build/src/gfx/skia/skia/src/gpu/GrRenderTargetOpList.cpp:88
    #4 0x7efca4bdbb69 in GrOpList::prepare(GrOpFlushState*) /builds/worker/workspace/build/src/gfx/skia/skia/src/gpu/GrOpList.cpp:84:11
    #5 0x7efca4bbcbee in GrDrawingManager::executeOpLists(int, int, GrOpFlushState*) /builds/worker/workspace/build/src/gfx/skia/skia/src/gpu/GrDrawingManager.cpp:276:22
    #6 0x7efca4bbb9f6 in GrDrawingManager::internalFlush(GrSurfaceProxy*, GrResourceCache::FlushType, int, GrBackendSemaphore*) /builds/worker/workspace/build/src/gfx/skia/skia/src/gpu/GrDrawingManager.cpp:224:23
    #7 0x7efca4bada9b in flush /builds/worker/workspace/build/src/gfx/skia/skia/src/gpu/GrDrawingManager.h:99:22
    #8 0x7efca4bada9b in GrDrawingManager::prepareSurfaceForExternalIO(GrSurfaceProxy*, int, GrBackendSemaphore*) /builds/worker/workspace/build/src/gfx/skia/skia/src/gpu/GrDrawingManager.cpp:335
    #9 0x7efca4c25633 in GrRenderTargetContext::prepareForExternalIO(int, GrBackendSemaphore*) /builds/worker/workspace/build/src/gfx/skia/skia/src/gpu/GrRenderTargetContext.cpp:1390:36
.
.
.

Comment 19

[Atte Kettunen]

Note: The ESR60 build fuzzfetch downloaded is, according to about page, 60.3.1esr. Comment 12, says that the fix is approved for 60.4.0esr.

Comment 20

[Julien Cristau [:jcristau] (back April 22)]

Lee, from comment 18 it seems esr60 is still affected?

Comment 21

[Julien Cristau [:jcristau] (back April 22)]

(In reply to Atte Kettunen from comment #19)
> Note: The ESR60 build fuzzfetch downloaded is, according to about page,
> 60.3.1esr. Comment 12, says that the fix is approved for 60.4.0esr.

The version bump to 60.4.0 hasn't happened yet, so that's expected.  AFAICT the build you downloaded includes the patch from this bug.

Comment 22

[Oana Botisan, Desktop QA]

Considering the fact that I can't reproduce the issue. I will take out the qe-verify+ flag. 
These are the buildID ( 20181125220116 ) and REV ( https://hg.mozilla.org/mozilla-central/rev/def0fd8429f955dcd8f29ae54cd2e2e5cd28032d) for the latest Nightly 65.

Comment 23

[Lee Salzman [:lsalzman]]

(In reply to Julien Cristau [:jcristau] from comment #20)
> Lee, from comment 18 it seems esr60 is still affected?

Whatever is left, as far as I can see, is a bug in Intel's Linux driver (confined to Linux with Intel IGP) and nothing we can actually fix. The platform independent aspect of this bug is what did get fixed. We don't enable accelerated canvas2d by default anywhere, so this shouldn't be much of a threat.