1211262 - (CVE-2015-7194) Arbitrary memory access in libjar (libxul)

Status: VERIFIED FIXED

(Core :: Networking: JAR, defect)

Description

[Gustavo Grieco]

Attachment: test.xpi

User Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:41.0) Gecko/20100101 Firefox/41.0
Build ID: 20150918100310

Steps to reproduce:

An arbitrary memory access was found in libjar using a specially crafted zip. It was tested in the libjar code shipped in Firefox 41 as well as Firefox 44.0a1. To reproduce this issue, find attached a test case (causing reading outside the buffers bounds in heap or stack randomly) and a JavaScript file to trigger this vulnerability in xpcshell (available in the xulrunner-sdk).
This particular xpi file is rejected by Firefox if you try to install them as extension, but we believe it could be modified to have a valid install.rdf file and cause the crash in parsing of an extension to install. At this point, i think it is quite important to know if this issue can be easily exploited remotely without user intervention.


Actual results:

The report of a debugger (x86) is available here:

$ LD_LIBRARY_PATH=".:./plugins:." gdb --args ./xpcshell test_open_xpi.js $(pwd)/test.xpi

Program received signal SIGSEGV, Segmentation fault.
0xb4429161 in nsJARInputStream::Read(char*, unsigned int, unsigned int*) () from ./libxul.so
(gdb) bt
#0  0xb4429161 in nsJARInputStream::Read(char*, unsigned int, unsigned int*) () from ./libxul.so
#1  0xb3fb3cca in nsScriptableInputStream::ReadHelper(char*, unsigned int) () from ./libxul.so
#2  0xb3fb3dee in nsScriptableInputStream::Read(unsigned int, char**) () from ./libxul.so
#3  0xb3fcf790 in NS_InvokeByIndex () from ./libxul.so
#4  0xb440bab9 in XPCWrappedNative::CallMethod(XPCCallContext&, XPCWrappedNative::CallMode) () from ./libxul.so
#5  0xb440ea7d in XPC_WN_CallMethod(JSContext*, unsigned int, JS::Value*) () from ./libxul.so
#6  0xb5dfec24 in js::Invoke(JSContext*, JS::CallArgs const&, js::MaybeConstruct) () from ./libxul.so
#7  0xb5dfa298 in Interpret(JSContext*, js::RunState&) () from ./libxul.so
#8  0xb5dfe675 in js::RunScript(JSContext*, js::RunState&) () from ./libxul.so
#9  0xb5dfe83a in js::ExecuteKernel(JSContext*, JS::Handle<JSScript*>, JSObject&, JS::Value const&, JS::Value const&, js::ExecuteType, js::AbstractFramePtr, JS::Value*) () from ./libxul.so
#10 0xb5dfe9b1 in js::Execute(JSContext*, JS::Handle<JSScript*>, JSObject&, JS::Value*) () from ./libxul.so
#11 0xb613e318 in ExecuteScript(JSContext*, JS::Handle<JSObject*>, JS::Handle<JSScript*>, JS::Value*) () from ./libxul.so
#12 0xb613e691 in JS_ExecuteScript(JSContext*, JS::Handle<JSScript*>, JS::MutableHandle<JS::Value>) () from ./libxul.so
#13 0xb4404ebb in ProcessFile(mozilla::dom::AutoJSAPI&, char const*, _IO_FILE*, bool) () from ./libxul.so
#14 0xb440529f in Process(mozilla::dom::AutoJSAPI&, char const*, bool) () from ./libxul.so
#15 0xb440899b in XRE_XPCShellMain () from ./libxul.so
#16 0x0804c42d in main (argc=4, argv=0xbffffb24, envp=0xbffffb38)
    at /builds/slave/m-cen-lx-000000000000000000000/build/src/js/xpconnect/shell/xpcshell.cpp:54
(gdb) x/i $eip
=> 0xb4429161 <_ZN16nsJARInputStream4ReadEPcjPj+187>:	rep movsb %ds:(%esi),%es:(%edi)
(gdb) info registers 
eax            0x2000004	33554436
ecx            0x1fde028	33415208
edx            0xaced5200	-1393733120
ebx            0xb7e4928c	-1209757044
esp            0xbfffdc00	0xbfffdc00
ebp            0xbfffdc18	0xbfffdc18
esi            0xafa9a000	-1347837952
edi            0xa6821fdc	-1501421604
eip            0xb4429161	0xb4429161 <nsJARInputStream::Read(char*, unsigned int, unsigned int*)+187>
eflags         0x210286	[ PF SF IF RF ID ]
cs             0x73	115
ss             0x7b	123
ds             0x7b	123
es             0x7b	123
fs             0x0	0
gs             0x33	51

and the report of Address Sanitizer (x86_64) is here:

==8811==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x7f3cd3729000 at pc 0x460117 bp 0x7fff821757d0 sp 0x7fff82174f90
READ of size 33554436 at 0x7f3cd3729000 thread T0
    #0 0x460116 (/home/g/Apps/firefox-asan/firefox/xpcshell+0x460116)
    #1 0x7f3ce83a646d (libxul.so+0x333a46d)
    #2 0x7f3ce71a657e (libxul.so+0x213a57e)
    #3 0x7f3ce71a6381 (libxul.so+0x213a381)
    #4 0x7f3ce721a704 (libxul.so+0x21ae704)
    #5 0x7f3ce8328571 (libxul.so+0x32bc571)
    #6 0x7f3ce8327f7f (libxul.so+0x32bbf7f)
    #7 0x7f3ce832be9b (libxul.so+0x32bfe9b)
    #8 0x7f3cee569ad2 (libxul.so+0x94fdad2)
    #9 0x7f3cee56904c (libxul.so+0x94fd04c)
    #10 0x7f3cee55b0e9 (libxul.so+0x94ef0e9)
    #11 0x7f3cee548e50 (libxul.so+0x94dce50)
    #12 0x7f3cee56bbb2 (libxul.so+0x94ffbb2)
    #13 0x7f3cee56c83d (libxul.so+0x950083d)
    #14 0x7f3ceee6a06c (libxul.so+0x9dfe06c)
    #15 0x7f3ceee69e04 (libxul.so+0x9dfde04)
    #16 0x7f3ce8366b74 (libxul.so+0x32fab74)
    #17 0x7f3ce8366e13 (libxul.so+0x32fae13)
    #18 0x7f3ce830792f (libxul.so+0x329b92f)
    #19 0x7f3ce8305049 (libxul.so+0x3299049)
    #20 0x48a94f (/home/g/Apps/firefox-asan/firefox/xpcshell+0x48a94f)
    #21 0x7f3ce19c9ec4 (/lib/x86_64-linux-gnu/libc.so.6+0x21ec4)
    #22 0x48a6cc (/home/g/Apps/firefox-asan/firefox/xpcshell+0x48a6cc)

0x7f3cd3729000 is located 6144 bytes to the left of 167422-byte region [0x7f3cd372a800,0x7f3cd37535fe)
freed by thread T0 here:
    #0 0x472ae1 (/home/g/Apps/firefox-asan/firefox/xpcshell+0x472ae1)
    #1 0x7f3cee193c30 (libxul.so+0x9127c30)
    #2 0x7f3cee66e9d3 (libxul.so+0x96029d3)
    #3 0x7f3ceee42a88 (libxul.so+0x9dd6a88)
    #4 0x7f3ce82b34c0 (libxul.so+0x32474c0)
    #5 0x7f3ce83445b3 (libxul.so+0x32d85b3)
    #6 0x7f3ce82d9958 (libxul.so+0x326d958)
    #7 0x7f3cec4750b4 (libxul.so+0x74090b4)
    #8 0x7f3ce71c5c8c (libxul.so+0x2159c8c)
    #9 0x7f3ce71c6bdd (libxul.so+0x215abdd)
    #10 0x7f3ce71c7a81 (libxul.so+0x215ba81)
    #11 0x7f3ce71c1226 (libxul.so+0x2155226)
    #12 0x7f3ce72690c4 (libxul.so+0x21fd0c4)
    #13 0x7f3ce724e0a4 (libxul.so+0x21e20a4)
    #14 0x7f3ce7240ae9 (libxul.so+0x21d4ae9)
    #15 0x7f3ce8304514 (libxul.so+0x3298514)
    #16 0x48a94f (/home/g/Apps/firefox-asan/firefox/xpcshell+0x48a94f)
    #17 0x7f3ce19c9ec4 (/lib/x86_64-linux-gnu/libc.so.6+0x21ec4)

previously allocated by thread T0 here:
    #0 0x472ce1 (/home/g/Apps/firefox-asan/firefox/xpcshell+0x472ce1)
    #1 0x7f3cee0b8d47 (libxul.so+0x904cd47)
    #2 0x7f3cee0b5d75 (libxul.so+0x9049d75)
    #3 0x7f3cee66e8bd (libxul.so+0x96028bd)
    #4 0x7f3ceee42a88 (libxul.so+0x9dd6a88)
    #5 0x7f3ce82b34c0 (libxul.so+0x32474c0)
    #6 0x7f3ce83445b3 (libxul.so+0x32d85b3)
    #7 0x7f3ce82d9958 (libxul.so+0x326d958)
    #8 0x7f3cec4750b4 (libxul.so+0x74090b4)
    #9 0x7f3ce71c5c8c (libxul.so+0x2159c8c)
    #10 0x7f3ce71c6bdd (libxul.so+0x215abdd)
    #11 0x7f3ce71c7a81 (libxul.so+0x215ba81)
    #12 0x7f3ce71c1226 (libxul.so+0x2155226)
    #13 0x7f3ce72690c4 (libxul.so+0x21fd0c4)
    #14 0x7f3ce724e0a4 (libxul.so+0x21e20a4)
    #15 0x7f3ce7240ae9 (libxul.so+0x21d4ae9)
    #16 0x7f3ce8304514 (libxul.so+0x3298514)
    #17 0x48a94f (/home/g/Apps/firefox-asan/firefox/xpcshell+0x48a94f)
    #18 0x7f3ce19c9ec4 (/lib/x86_64-linux-gnu/libc.so.6+0x21ec4)

SUMMARY: AddressSanitizer: heap-buffer-overflow ??:0 ??
Shadow bytes around the buggy address:
  0x0fe81a6dd1b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x0fe81a6dd1c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x0fe81a6dd1d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x0fe81a6dd1e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x0fe81a6dd1f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
=>0x0fe81a6dd200:[fa]fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0fe81a6dd210: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0fe81a6dd220: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0fe81a6dd230: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0fe81a6dd240: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0fe81a6dd250: 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
  Heap right redzone:      fb
  Freed heap region:       fd

and here:

==8782==ERROR: AddressSanitizer: stack-buffer-underflow on address 0x7fbb49f18a20 at pc 0x460117 bp 0x7fff6f1cbb70 sp 0x7fff6f1cb330
READ of size 33554436 at 0x7fbb49f18a20 thread T0
    #0 0x460116 (/home/g/Apps/firefox-asan/firefox/xpcshell+0x460116)
    #1 0x7fbb5e95b46d (libxul.so+0x333a46d)
    #2 0x7fbb5d75b57e (libxul.so+0x213a57e)
    #3 0x7fbb5d75b381 (libxul.so+0x213a381)
    #4 0x7fbb5d7cf704 (libxul.so+0x21ae704)
    #5 0x7fbb5e8dd571 (libxul.so+0x32bc571)
    #6 0x7fbb5e8dcf7f (libxul.so+0x32bbf7f)
    #7 0x7fbb5e8e0e9b (libxul.so+0x32bfe9b)
    #8 0x7fbb64b1ead2 (libxul.so+0x94fdad2)
    #9 0x7fbb64b1e04c (libxul.so+0x94fd04c)
    #10 0x7fbb64b100e9 (libxul.so+0x94ef0e9)
    #11 0x7fbb64afde50 (libxul.so+0x94dce50)
    #12 0x7fbb64b20bb2 (libxul.so+0x94ffbb2)
    #13 0x7fbb64b2183d (libxul.so+0x950083d)
    #14 0x7fbb6541f06c (libxul.so+0x9dfe06c)
    #15 0x7fbb6541ee04 (libxul.so+0x9dfde04)
    #16 0x7fbb5e91bb74 (libxul.so+0x32fab74)
    #17 0x7fbb5e91be13 (libxul.so+0x32fae13)
    #18 0x7fbb5e8bc92f (libxul.so+0x329b92f)
    #19 0x7fbb5e8ba049 (libxul.so+0x3299049)
    #20 0x48a94f (/home/g/Apps/firefox-asan/firefox/xpcshell+0x48a94f)
    #21 0x7fbb57f7eec4 (/lib/x86_64-linux-gnu/libc.so.6+0x21ec4)
    #22 0x48a6cc (/home/g/Apps/firefox-asan/firefox/xpcshell+0x48a6cc)

Address 0x7fbb49f18a20 is located in stack of thread T11 (JS Helper) at offset 0 in frame
    #0 0x7fbb64af130f (libxul.so+0x94d030f)

  This frame has 2 object(s):
    [32, 36) 'status' <== Memory access at offset 0 partially underflows this variable
    [48, 52) '' <== Memory access at offset 0 partially underflows this variable
HINT: this may be a false positive if your program uses some custom stack unwind mechanism or swapcontext
      (longjmp and C++ exceptions *are* supported)
Thread T11 (JS Helper) created by T0 here:
    #0 0x45f555 (/home/g/Apps/firefox-asan/firefox/xpcshell+0x45f555)
    #1 0x7fbb6ad15c14 (libnspr4.so+0x71c14)
    #2 0x7fbb6ad1572a (libnspr4.so+0x7172a)
    #3 0x7fbb64aefa7b (libxul.so+0x94cea7b)
    #4 0x7fbb64b83b88 (libxul.so+0x9562b88)
    #5 0x7fbb653f7170 (libxul.so+0x9dd6170)
    #6 0x7fbb5d68696b (libxul.so+0x206596b)
    #7 0x7fbb5e885761 (libxul.so+0x3264761)
    #8 0x7fbb5e889355 (libxul.so+0x3268355)
    #9 0x7fbb5e8f91ef (libxul.so+0x32d81ef)
    #10 0x7fbb5e8f94da (libxul.so+0x32d84da)
    #11 0x7fbb5e88e958 (libxul.so+0x326d958)
    #12 0x7fbb62a2a0b4 (libxul.so+0x74090b4)
    #13 0x7fbb5d77ac8c (libxul.so+0x2159c8c)
    #14 0x7fbb5d77bbdd (libxul.so+0x215abdd)
    #15 0x7fbb5d77ca81 (libxul.so+0x215ba81)
    #16 0x7fbb5d776226 (libxul.so+0x2155226)
    #17 0x7fbb5d81e0c4 (libxul.so+0x21fd0c4)
    #18 0x7fbb5d8030a4 (libxul.so+0x21e20a4)
    #19 0x7fbb5d7f5ae9 (libxul.so+0x21d4ae9)
    #20 0x7fbb5e8b9514 (libxul.so+0x3298514)
    #21 0x48a94f (/home/g/Apps/firefox-asan/firefox/xpcshell+0x48a94f)
    #22 0x7fbb57f7eec4 (/lib/x86_64-linux-gnu/libc.so.6+0x21ec4)

SUMMARY: AddressSanitizer: stack-buffer-underflow ??:0 ??
Shadow bytes around the buggy address:
  0x0ff7e93db0f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x0ff7e93db100: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x0ff7e93db110: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x0ff7e93db120: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x0ff7e93db130: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
=>0x0ff7e93db140: 00 00 00 00[f1]f1 f1 f1 04 f2 04 f3 00 00 00 00
  0x0ff7e93db150: 00 00 00 00 00 00 00 00 00 00 00 00 f1 f1 f1 f1
  0x0ff7e93db160: 00 f2 f2 f2 01 f2 00 f3 f3 f3 f3 f3 00 00 00 00
  0x0ff7e93db170: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x0ff7e93db180: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x0ff7e93db190: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
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
  Heap right redzone:      fb
  Freed heap region:       fd
  Stack left redzone:      f1


Expected results:

It shouldn't crash.

Comment 1

[Gustavo Grieco]

Attachment: test_open_xpi.js

Comment 2

[Benjamin Smedberg]

Most serious exploit risk is via jar: URIs which are available to content without prompting.

Comment 3

[Gustavo Grieco]

(In reply to Benjamin Smedberg  [:bsmedberg] from comment #2)
> Most serious exploit risk is via jar: URIs which are available to content
> without prompting.

Interesting. I uploaded the POC to try here:

jar:http://dcc.fceia.unr.edu.ar/~ggrieco/crash.jar!/Z%C2%A9

Comment 4

[Andrew McCreight [:mccr8]]

Is this something you could look into, Aaron? Thanks.

Comment 5

[Liz Henry (:lizzard) (relman/hg->git project)]

sec-high, affects 41 and 44, likely affects the releases in between.

Comment 6

[(No longer employed by Mozilla) Aaron Klotz]

Yeah, Taras would usually send me all the libjar bugs anyway.

Comment 7

[Gustavo Grieco]

I was wondering if is it really necessary to support jar: links nowadays?

Comment 8

[(No longer employed by Mozilla) Aaron Klotz]

Attachment: Patch

Comment 9

[Michael Wu [:mwu]]

Comment on attachment 8671481 [details] [diff] [review]
Patch

Review of attachment 8671481 [details] [diff] [review]:
-----------------------------------------------------------------

This looks right to me. I'm really surprised that nsJARInputStream::Read is using mOutSize to determine how much data we can copy. mZs.avail_in/nsZipItem::Size() is what bounds the data we can read from the buffer and the nsZipCursor code correctly uses that for STORED entries. If you can get a pointer from nsZipArchive::GetData, it guarantees that up to nsZipItem::Size() bytes can be read. Maybe we can make nsZipArchive::GetData do more sanity checking instead? This would also protect other users of nsZipArchive like nsZipCursor/nsZipItemPtr and make it slightly less obvious which code path is handling broken STORED entries wrong.

Comment 10

[(No longer employed by Mozilla) Aaron Klotz]

Attachment: Patch (r2)

This revision moves the check into nsZipArchive and also revises nsJARInputStream::Read to use the safer variable.

Comment 11

[Michael Wu [:mwu]]

Comment on attachment 8671527 [details] [diff] [review]
Patch (r2)

Review of attachment 8671527 [details] [diff] [review]:
-----------------------------------------------------------------

r=me without the changes in jsJARInputStream.cpp, which I think we can tackle separately.

::: modules/libjar/nsJARInputStream.cpp
@@ +205,5 @@
>          break;
>  
>        case MODE_COPY:
>          if (mFd) {
> +          uint32_t count = std::min(aCount, uint32_t(mZs.avail_in) - uint32_t(mZs.total_out));

I think this is a little weird - avail_in is suppose to be updated whenever we read data from the buffer, so this isn't quite right. I think it would be sufficient to stick with the fix in nsZipArchive.cpp and come back to this later if you want.

::: modules/libjar/nsZipArchive.cpp
@@ +841,5 @@
>    // -- check if there is enough source data in the file
>    if (!offset ||
>        mFd->mLen < aItem->Size() ||
> +      offset > mFd->mLen - aItem->Size() ||
> +      aItem->Compression() == STORED && aItem->Size() != aItem->RealSize()) {

Had to look up operator precedence to figure out if this was right.

::: modules/libjar/test/unit/test_corrupt_1211262.js
@@ +1,5 @@
> +/* Any copyright is dedicated to the Public Domain.
> + * http://creativecommons.org/publicdomain/zero/1.0/
> + */
> +
> +// Regression test ensuring that that a STORED entry with differing comparessed

s/comparessed/compressed/

Comment 12

[(No longer employed by Mozilla) Aaron Klotz]

Attachment: Patch (r3)

Incorporated review feedback. Carrying forward r+.

Comment 13

[(No longer employed by Mozilla) Aaron Klotz]

Comment on attachment 8671564 [details] [diff] [review]
Patch (r3)

[Security approval request comment]
How easily could an exploit be constructed based on the patch?
Pretty easily; somebody would just need to generate a specially crafted ZIP that meets the condition in the patch.

Do comments in the patch, the check-in comment, or tests included in the patch paint a bulls-eye on the security problem?
There is mentioning of ZIP corruption.

Which older supported branches are affected by this flaw?
All supported branches

If not all supported branches, which bug introduced the flaw?
N/A

Do you have backports for the affected branches? If not, how different, hard to create, and risky will they be?
Should be a simple hg graft. No risk.

How likely is this patch to cause regressions; how much testing does it need?
Added a new xpcshell test for this condition. Other existing tests pass. Unlikely to cause regressions since our code doesn't support encrypted ZIPs (in that case the condition added by this patch would be incorrect).

Comment 14

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

Sec-approval+ but the test needs to not land until after we ship a release with this fix so we don't 0 day ourselves by showing everyone how to easily trigger this.

We'll want this on Aurora, Beta, and ESR38. Please nominate patches for these.

Comment 15

[(No longer employed by Mozilla) Aaron Klotz]

Attachment: Patch containing fix only

[Approval Request Comment]
If this is not a sec:{high,crit} bug, please state case for ESR consideration:
This is sec-high

User impact if declined:
A specially crafted ZIP file could be loaded (via jar:// url or other means) that causes Firefox to read invalid memory

Fix Landed on Version:
To be landed on 42, 43, 44

Risk to taking this patch (and alternatives if risky): 
Low, adds a simple sanity check

String or UUID changes made by this patch: None

See https://wiki.mozilla.org/Release_Management/ESR_Landing_Process for more info.

Approval Request Comment
[Feature/regressing bug #]: libjar
[User impact if declined]: A specially crafted ZIP file could be loaded (via jar:// url or other means) that causes Firefox to read invalid memory
[Describe test coverage new/current, TreeHerder]: Locally. Wrote regression test to be landed later once security fix is in release channel.
[Risks and why]: Low, adds a simple sanity check
[String/UUID change made/needed]: None

Comment 16

[(No longer employed by Mozilla) Aaron Klotz]

https://hg.mozilla.org/integration/mozilla-inbound/rev/6d7a8e19086c

Comment 17

[Wes Kocher (:KWierso) (Not reading bugmail; email directly if needed)]

I had to back this out for wError bustage: https://treeherder.mozilla.org/logviewer.html#?job_id=15570048&repo=mozilla-inbound
https://hg.mozilla.org/integration/mozilla-inbound/rev/bf4b1c2d2a6e

Comment 18

[(No longer employed by Mozilla) Aaron Klotz]

Attachment: Patch containing fix only (r2)

Busted because MSVC doesn't give me those warnings. Fixed, carrying forward r+.

See comment 15 for approval request info.

Comment 19

[(No longer employed by Mozilla) Aaron Klotz]

https://hg.mozilla.org/integration/mozilla-inbound/rev/673d9f45b802

Comment 20

[Carsten Book [:Tomcat]]

https://hg.mozilla.org/mozilla-central/rev/673d9f45b802

Comment 21

[Liz Henry (:lizzard) (relman/hg->git project)]

Comment on attachment 8673327 [details] [diff] [review]
Patch containing fix only (r2)

OK to uplift to aurora and beta, looks ok on m-c.

Comment 22

[(No longer employed by Mozilla) Aaron Klotz]

ni? myself so that I remember to land the tests later.

Comment 23

[Carsten Book [:Tomcat]]

https://hg.mozilla.org/releases/mozilla-aurora/rev/d32d0321812f

Comment 24

[Carsten Book [:Tomcat]]

(In reply to Carsten Book [:Tomcat] from comment #23)
> https://hg.mozilla.org/releases/mozilla-aurora/rev/d32d0321812f

sorry had to back this out for bustage on aurora like https://treeherder.mozilla.org/logviewer.html#?job_id=1326385&repo=mozilla-aurora

Comment 25

[(No longer employed by Mozilla) Aaron Klotz]

Attachment: Patch containing fix only (r3)

OK, here's the actual patch as landed on central. r2 *should* have been this one.

Comment 26

[(No longer employed by Mozilla) Aaron Klotz]

Still need to ni? myself, oops.

Comment 27

[(No longer employed by Mozilla) Aaron Klotz]

https://hg.mozilla.org/releases/mozilla-aurora/rev/e32e829c8bbf
https://hg.mozilla.org/releases/mozilla-beta/rev/db9d3e806685

Comment 28

[Ritu Kothari (:ritu) (Inactive, please n-i to RyanVM, jcristau, or pascal)]

Aaron, Tomcat: We will need this to patch to land on ESR branch too. Could you please uplift? Thanks!

Comment 29

[Ritu Kothari (:ritu) (Inactive, please n-i to RyanVM, jcristau, or pascal)]

Comment on attachment 8673327 [details] [diff] [review]
Patch containing fix only (r2)

Taking this in esr38.4.0 as this is a sec-high which has also landed on Beta42 and Aurora43.

Comment 30

[Wes Kocher (:KWierso) (Not reading bugmail; email directly if needed)]

https://hg.mozilla.org/releases/mozilla-esr38/rev/6e2ad36d85fe

Comment 31

[Ada [:adalucinet]]

While following STR provided in comment 0, indeed I cannot install the xpi file; and while using the testcase in Nightly debug from 2015-10-04, the build unexpectedly close under Ubuntu 12.04 64-bit. Is there any other xpi that I could test with? Or different STR? Aaron, what's your take on this?

Gustavo, could you please check the latest builds to see if this is fixed for you? Thanks in advance!

Comment 32

[Gustavo Grieco]

Sure, i will test it later today. Indeed the xpi file cannot be installed but you can check this same bug using jar links (it is the same crasher, but accesing directly as zip). Just load this link into your firefox build:

jar:http://dcc.fceia.unr.edu.ar/~ggrieco/crash.jar!/Z%C2%A9

Comment 33

[Ada [:adalucinet]]

(In reply to Gustavo Grieco from comment #32)
> Sure, i will test it later today. 
Great! Thank you!

> Indeed the xpi file cannot be installed but you can check this same bug using jar links (it is the same crasher, but
> accesing directly as zip). Just load this link into your firefox build:
> jar:http://dcc.fceia.unr.edu.ar/~ggrieco/crash.jar!/Z%C2%A9

Already tried it (via comment 3), but the file is no longer there: "The requested URL was not found on this server." is displayed.

Comment 34

[Gustavo Grieco]

It looks http://dcc.fceia.unr.edu.ar/~ggrieco/crash.jar is working correctly here. 

Have you copy and pasted the jar link directly into the browser address bar?

Comment 35

[Gustavo Grieco]

I can confirm: no crash in the last build from tinderbox (20151020150039). I tried the jar: link and the xpcshell test script. Great job guys!

(btw, i'm running QuickFuzz again just in case)

Comment 36

[Ada [:adalucinet]]

(In reply to Gustavo Grieco from comment #35)
> I can confirm: no crash in the last build from tinderbox (20151020150039). I
> tried the jar: link and the xpcshell test script. Great job guys!
> 
> (btw, i'm running QuickFuzz again just in case)

Thanks, Gustavo! Marking accordingly based on your result.

Comment 37

[(No longer employed by Mozilla) Aaron Klotz]

https://hg.mozilla.org/integration/mozilla-inbound/rev/0862bfe2c7ec737a13759d9fde30d71d8d14394d
Bug 1211262: Unit test; r=mwu

Comment 38

[(No longer employed by Mozilla) Aaron Klotz]

The unit test has landed.

Comment 39

[Carsten Book [:Tomcat]]

https://hg.mozilla.org/mozilla-central/rev/0862bfe2c7ec