1098137 - heap-buffer-overflow (read of size 20) below mozilla::dom::WebGLRenderingContextBinding::generateMipmap

Status: RESOLVED WORKSFORME

(Core :: Graphics: CanvasWebGL, defect)

Description

[Aki Helin]

Attachment: ffl-bofr-gl.html

At least current tinderbox ASan build spots a heap buffer overflow when the attached page is opened.

==20129==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x6020002bbbb8 at pc 0x43d220 bp 0x7fff0d4a0060 sp 0x7fff0d4a0028
READ of size 20 at 0x6020002bbbb8 thread T0
    #0 0x43d21f in memcmp _asan_rtl_
    #1 0x7f4bba7266c5 in ?? ??:0
    #2 0x7f4bba78181b in ?? ??:0
    #3 0x7f4bba6b1d41 in ?? ??:0
    #4 0x7f4bba6b2870 in ?? ??:0
    #5 0x7f4bba64c494 in ?? ??:0
    #6 0x7f4bba7d7c38 in ?? ??:0
    #7 0x7f4bba7d825a in ?? ??:0
    #8 0x7f4bba6f2518 in ?? ??:0
    #9 0x7f4bba77f0af in ?? ??:0
    #10 0x7f4bba6709e1 in ?? ??:0
    #11 0x7f4be236b1e9 in nsRefPtr<mozilla::gl::GLContext>::operator->() const /home/aki/src/mozilla-aurora/objdir-ff-asan/dom/canvas/../../dist/include/GLContext.h:1344
    #12 0x7f4be21ef350 in mozilla::dom::WebGLRenderingContextBinding::generateMipmap(JSContext*, JS::Handle<JSObject*>, mozilla::WebGLContext*, JSJitMethodCallArgs const&) /home/aki/src/mozilla-aurora/objdir-ff-asan/dom/bindings/./WebGLRenderingContextBinding.cpp:10582
    #13 0x7f4be22aa15f in mozilla::dom::GenericBindingMethod(JSContext*, unsigned int, JS::Value*) /home/aki/src/mozilla-aurora/dom/bindings/BindingUtils.cpp:2406
    #14 0x7f4be83ec98c in js::CallJSNative(JSContext*, bool (*)(JSContext*, unsigned int, JS::Value*), JS::CallArgs const&) /home/aki/src/mozilla-aurora/js/src/jscntxtinlines.h:231
    #15 0x7f4be83dbe33 in Interpret(JSContext*, js::RunState&) /home/aki/src/mozilla-aurora/js/src/vm/Interpreter.cpp:2546
    #16 0x7f4be83b14e6 in js::RunScript(JSContext*, js::RunState&) /home/aki/src/mozilla-aurora/js/src/vm/Interpreter.cpp:431
    #17 0x7f4be83f139d in js::ExecuteKernel(JSContext*, JS::Handle<JSScript*>, JSObject&, JS::Value const&, js::ExecuteType, js::AbstractFramePtr, JS::Value*) /home/aki/src/mozilla-aurora/js/src/vm/Interpreter.cpp:637
    #18 0x7f4be83f1c73 in js::Execute(JSContext*, JS::Handle<JSScript*>, JSObject&, JS::Value*) /home/aki/src/mozilla-aurora/js/src/vm/Interpreter.cpp:673
    #19 0x7f4be7db4e10 in Evaluate(JSContext*, JS::Handle<JSObject*>, JS::ReadOnlyCompileOptions const&, JS::SourceBufferHolder&, JS::Value*) /home/aki/src/mozilla-aurora/js/src/jsapi.cpp:4826
[...]

Comment 1

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

Milan, can you suggest someone to look at this?

Comment 2

[Milan Sreckovic [:milan] (needinfo for best results)]

I'm having trouble reproducing this with linux 64 asan build from https://ftp.mozilla.org/pub/mozilla.org/firefox/tinderbox-builds/mozilla-central-linux64-asan/.  Is it still around in the nightly?

Comment 3

[Aki Helin]

Sigh. Seems to have been fixed more or less intentionally within the last few weeks. I checked during the first week or so that it reproduced with latest builds.

Comment 4

[Daniel Veditz [:dveditz]]

Reopening. Kamil: please check this in ASAN builds on our to-be-shipped branches. We might need to bisect to find the fix and then back-port it to beta or something.

Comment 5

[Kamil Jozwiak [:kjozwiak]]

I tried reproducing the original issue from comment #0 using m-c asan builds from around the same date the ticket was created . Unfortunately, I couldn't reproduce the original problem. Used the following builds:

* http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/2014/11/2014-11-27-03-02-08-mozilla-central/
* http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/2014/11/2014-11-16-03-02-12-mozilla-central/
* http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/2014/12/2014-12-01-03-02-07-mozilla-central/
* http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/2014/12/2014-12-05-03-02-02-mozilla-central/
* http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/2014/12/2014-12-12-03-02-01-mozilla-central/
* http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/2014/12/2014-12-14-03-02-05-mozilla-central/

I also tried reproducing the issue on the latest m-c, m-a and m-b asan builds without any luck either. Used the following builds:

* http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/2015-01-16-03-02-03-mozilla-central/
* http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/2015-01-16-00-40-07-mozilla-aurora/
* http://inbound-archive.pub.build.mozilla.org/pub/mozilla.org/firefox/tinderbox-builds/mozilla-beta-linux64-asan/1421421606/

Test Cases used:

- Opened the poc added in comment #0 several times with e10s enabled (opened several tabs)
- Opened the poc added in comment #0 several times without e10s enabled (opened several tabs)
- Restarted the browser a few times and tried re-opening the POC

Dan, is there anything else I can do here? Should I try builds that are a lot earlier?

Comment 6

[Daniel Veditz [:dveditz]]

Thanks for checking! Those two November builds should have reproduced the problem according to comment 3, at least, and maybe some of the December ones depending on how many weeks Aki meant. I'm much less worried we're shipping an unfixed problem, but there's still a little bit of worry about why we can't repro.

Hard to imagine that we're testing incorrectly if it's as simple as "load this attachment". Does the attachment have to be loaded from somewhere other than a bugzilla attachment to reproduce? There are no external resources referenced so that seems unlikely.

What are all those "??" frames in the stack trace? If they're JITted JS then the bug should be reproduceable and be our fault. Is it possible they're in the graphics drivers on Aki's machine?

Did Aki have non-default pref settings that would change how code was JITted?

Aki: any ideas on what we can do differently to reproduce your crash in a November 2014 ASAN build? If not is it OK to resolve this worksforme again?

Comment 7

[Aki Helin]

I can't seem to reproduce it here either. I wonder if there has been a driver update in the meantime... At the time the bug was filed, it seemed obvious that the buffer size overflowed something within GL. I was able to change sizes so that the bug reproduced with suitable powers of two. Now I'm seeing an error about size and count being too large in older builds, and nothing in newer ones. I tried grepping through the current source to see whether that is printed before or after going to GL, but found nothing. I'm guessing now GL reports back an error about the buffer size instead of failing to handle it correctly, and possibly now FF also checks the size before trying.

Comment 8

[Daniel Veditz [:dveditz]]

Unfortunately I think we're going to have to write this one off as a driver bug. Please let us know if you run across it again.

Comment 9

[Aki Helin]

@dvediz ref running into this again, it does still reproduce on one machine, but seems indeed to be a driver thing. The overflow happens in /usr/lib/x86_64-linux-gnu/dri/i965_dri.so on my server edition Ubuntu 14.04 machine with i7 2600 and the integrated GPU, but does not happen on the same hardware when using an up-to-date Debian, nor did it happen on a few other machines with Intel GPUs, so it's likely a pretty rare issue.