719779 - AddressSanitizer heap-use-after-free READ of size 4

Status: RESOLVED DUPLICATE of bug 711653

(Core :: SVG, defect)

Description

[Atte Kettunen]

Repro-file as attachment.

=================================================================
==30970== ERROR: AddressSanitizer heap-use-after-free on address 0x7f27b7b2ddc0 at pc 0x7f27da1a44d0 bp 0x7f27b60a22c0 sp 0x7f27b60a22b8
READ of size 4 at 0x7f27b7b2ddc0 thread T15
    #0 0x7f27da1a44d0 (/home/ouspg/firefox/objdir-ff-asan/toolkit/library/libxul.so+0x9b34d0)
    #1 0x7f27db952353 (/home/ouspg/firefox/objdir-ff-asan/toolkit/library/libxul.so+0x2161353)
    #2 0x7f27db953747 (/home/ouspg/firefox/objdir-ff-asan/toolkit/library/libxul.so+0x2162747)
    #3 0x7f27dbfe91cd (/home/ouspg/firefox/objdir-ff-asan/toolkit/library/libxul.so+0x27f81cd)
    #4 0x7f27dc07b53d (/home/ouspg/firefox/objdir-ff-asan/toolkit/library/libxul.so+0x288a53d)
    #5 0x7f27dff2074c (/home/ouspg/firefox/objdir-ff-asan/nsprpub/pr/src/libnspr4.so+0x1d374c)
    #6 0x40ed22 (/home/ouspg/firefox/objdir-ff-asan/dist/bin/firefox+0x40ed22)
0x7f27b7b2ddc0 is located 64 bytes inside of 120-byte region [0x7f27b7b2dd80,0x7f27b7b2ddf8)
freed by thread T0 here:
    #0 0x40ad84 (/home/ouspg/firefox/objdir-ff-asan/dist/bin/firefox+0x40ad84)
    #1 0x7f27db654211 (/home/ouspg/firefox/objdir-ff-asan/toolkit/library/libxul.so+0x1e63211)
    #2 0x7f27dbfed1c2 (/home/ouspg/firefox/objdir-ff-asan/toolkit/library/libxul.so+0x27fc1c2)
    #3 0x7f27dbfe91cd (/home/ouspg/firefox/objdir-ff-asan/toolkit/library/libxul.so+0x27f81cd)
    #4 0x7f27dbe87628 (/home/ouspg/firefox/objdir-ff-asan/toolkit/library/libxul.so+0x2696628)
    #5 0x7f27dc0eefdf (/home/ouspg/firefox/objdir-ff-asan/toolkit/library/libxul.so+0x28fdfdf)
    #6 0x7f27dbc95b4c (/home/ouspg/firefox/objdir-ff-asan/toolkit/library/libxul.so+0x24a4b4c)
    #7 0x405d82 (/home/ouspg/firefox/objdir-ff-asan/dist/bin/firefox+0x405d82)
    #8 0x40547a (/home/ouspg/firefox/objdir-ff-asan/dist/bin/firefox+0x40547a)
    #9 0x7f27e1193eff (/lib/x86_64-linux-gnu/libc-2.13.so+0x1eeff)
previously allocated by thread T0 here:
    #0 0x40ae64 (/home/ouspg/firefox/objdir-ff-asan/dist/bin/firefox+0x40ae64)
    #1 0x7f27df71413d (/home/ouspg/firefox/objdir-ff-asan/memory/mozalloc/libmozalloc.so+0x113d)
    #2 0x7f27db629960 (/home/ouspg/firefox/objdir-ff-asan/toolkit/library/libxul.so+0x1e38960)
    #3 0x7f27db6291c4 (/home/ouspg/firefox/objdir-ff-asan/toolkit/library/libxul.so+0x1e381c4)
    #4 0x7f27db66c3a6 (/home/ouspg/firefox/objdir-ff-asan/toolkit/library/libxul.so+0x1e7b3a6)
    #5 0x7f27db67b582 (/home/ouspg/firefox/objdir-ff-asan/toolkit/library/libxul.so+0x1e8a582)
    #6 0x7f27dc788739 (/home/ouspg/firefox/objdir-ff-asan/toolkit/library/libxul.so+0x2f97739)
    #7 0x7f27dc77ea8a (/home/ouspg/firefox/objdir-ff-asan/toolkit/library/libxul.so+0x2f8da8a)
    #8 0x7f27dc76a30e (/home/ouspg/firefox/objdir-ff-asan/toolkit/library/libxul.so+0x2f7930e)
    #9 0x7f27dc6c82e1 (/home/ouspg/firefox/objdir-ff-asan/toolkit/library/libxul.so+0x2ed72e1)
Thread T15 created by T0 here:
    #0 0x40cd45 (/home/ouspg/firefox/objdir-ff-asan/dist/bin/firefox+0x40cd45)
    #1 0x7f27dff122b9 (/home/ouspg/firefox/objdir-ff-asan/nsprpub/pr/src/libnspr4.so+0x1c52b9)
    #2 0x7f27dff10968 (/home/ouspg/firefox/objdir-ff-asan/nsprpub/pr/src/libnspr4.so+0x1c3968)
    #3 0x7f27dc07bd5e (/home/ouspg/firefox/objdir-ff-asan/toolkit/library/libxul.so+0x288ad5e)
    #4 0x7f27dc080771 (/home/ouspg/firefox/objdir-ff-asan/toolkit/library/libxul.so+0x288f771)
==30970== ABORTING
Stats: 273M malloced (198M for red zones) by 243753 calls
Stats: 203M realloced by 15903 calls
Stats: 249M freed by 131653 calls
Stats: 83M really freed by 127479 calls
Stats: 512M (131176 full pages) mmaped in 128 calls
  mmaps   by size class: 8:212979; 9:32764; 10:12285; 11:8188; 12:2048; 13:1024; 14:768; 15:256; 16:704; 17:64; 18:96; 19:72; 20:132; 21:66; 22:1; 
  mallocs by size class: 8:202641; 9:22893; 10:8281; 11:5727; 12:1739; 13:737; 14:509; 15:163; 16:673; 17:39; 18:86; 19:69; 20:130; 21:65; 22:1; 
  frees   by size class: 8:105513; 9:14133; 10:5855; 11:3050; 12:1084; 13:578; 14:355; 15:127; 16:623; 17:34; 18:41; 19:66; 20:129; 21:64; 22:1; 
  rfrees  by size class: 8:103294; 9:13561; 10:5516; 11:2786; 12:986; 13:559; 14:353; 15:115; 16:131; 17:34; 18:41; 19:66; 20:37; 
Stats: malloc large: 390 small slow: 1232
Shadow byte and word:
  0x1fe4f6f65bb8: fd
  0x1fe4f6f65bb8: fd fd fd fd fd fd fd fd
More shadow bytes:
  0x1fe4f6f65b98: fb fb fb fb fb fb fb fb
  0x1fe4f6f65ba0: fa fa fa fa fa fa fa fa
  0x1fe4f6f65ba8: fa fa fa fa fa fa fa fa
  0x1fe4f6f65bb0: fd fd fd fd fd fd fd fd
=>0x1fe4f6f65bb8: fd fd fd fd fd fd fd fd
  0x1fe4f6f65bc0: fa fa fa fa fa fa fa fa
  0x1fe4f6f65bc8: fa fa fa fa fa fa fa fa
  0x1fe4f6f65bd0: fd fd fd fd fd fd fd fd
  0x1fe4f6f65bd8: fd fd fd fd fd fd fd fd

When I changed values from the following line into smaller ones I also got the following asan report.

<g transform="matrix(10000,-256152303,30000,10000,30000,30000) " filter="url(#MyFilter)" />

=================================================================
==658== ERROR: AddressSanitizer heap-buffer-overflow on address 0x7fd48bf1f587 at pc 0x7fd4b0dc6033 bp 0x7fff1fd95ca0 sp 0x7fff1fd95c98
READ of size 1 at 0x7fd48bf1f587 thread T0
    #0 0x7fd4b0dc6033 (/home/ouspg/firefox/objdir-ff-asan/toolkit/library/libxul.so+0x1d60033)
0x7fd48bf1f587 is located 3 bytes to the right of 4-byte region [0x7fd48bf1f580,0x7fd48bf1f584)
allocated by thread T0 here:
    #0 0x40b0de (/home/ouspg/firefox/objdir-ff-asan/dist/bin/firefox+0x40b0de)
    #1 0x7fd4b19e872c (/home/ouspg/firefox/objdir-ff-asan/toolkit/library/libxul.so+0x298272c)
    #2 0x7fd4b19e837d (/home/ouspg/firefox/objdir-ff-asan/toolkit/library/libxul.so+0x298237d)
==658== ABORTING
Stats: 57M malloced (81M for red zones) by 237008 calls
Stats: 3M realloced by 11503 calls
Stats: 32M freed by 109983 calls
Stats: 0M really freed by 0 calls
Stats: 172M (44051 full pages) mmaped in 43 calls
  mmaps   by size class: 8:212979; 9:32764; 10:12285; 11:8188; 12:2048; 13:1024; 14:512; 15:256; 16:256; 17:32; 18:64; 19:8; 20:4; 
  mallocs by size class: 8:195729; 9:24760; 10:7751; 11:5369; 12:1596; 13:825; 14:488; 15:176; 16:231; 17:23; 18:53; 19:5; 20:2; 
  frees   by size class: 8:86196; 9:13808; 10:4962; 11:2807; 12:954; 13:642; 14:265; 15:139; 16:179; 17:18; 18:10; 19:2; 20:1; 
  rfrees  by size class: 
Stats: malloc large: 83 small slow: 1002
Shadow byte and word:
  0x1ffa917e3eb0: 4
  0x1ffa917e3eb0: 04 fb fb fb fb fb fb fb
More shadow bytes:
  0x1ffa917e3e90: 00 00 00 00 00 00 00 00
  0x1ffa917e3e98: 00 fb fb fb fb fb fb fb
  0x1ffa917e3ea0: fa fa fa fa fa fa fa fa
  0x1ffa917e3ea8: fa fa fa fa fa fa fa fa
=>0x1ffa917e3eb0: 04 fb fb fb fb fb fb fb
  0x1ffa917e3eb8: fb fb fb fb fb fb fb fb
  0x1ffa917e3ec0: fa fa fa fa fa fa fa fa
  0x1ffa917e3ec8: fa fa fa fa fa fa fa fa
  0x1ffa917e3ed0: 00 fb fb fb fb fb fb fb

Comment 1

[Atte Kettunen]

Attachment: original testcase (doesn't reliably reproduce bug)

Comment 2

[Atte Kettunen]

together with some other files this reported as use-after-free READ size 8. So far I have been unable to point exact file combination needed for the issue but I'll try again asap.

Comment 3

[Daniel Veditz [:dveditz]]

decoder: please get us a stack with symbols for this error

Comment 4

[Christian Holler (:decoder)]

@Atte:

I was not able to reproduce your crash so far (I tried an older build + a new build from mozilla-central tip now both on 64 bit opt/dbg). Can you give me more information on the build you are using? (revision, build config, etc). Is there any special reproduction step required besides just opening the SVG (also tried using it in an img tag from HTML)?

Also, can you run your ASan trace through the symbolize script supplied with ASan (scripts/asan_symbolize.py)? Something like "cat yourlog.txt | python asan_symbolize.py | c++filt" would be good. If you have the choice, do this on a debug build for a better trace.

Comment 5

[Atte Kettunen]

@Christian:

Before I reported this I built new ASAN build from the mozilla-central source at that time. I'm unable to reproduce the READ of size 4 with my current build. 

When I change the values from the repro-file into 

<g transform="matrix(100,-2562303,3000,100,300,300) " filter="url(#MyFilter)"/>

I can still get crash with report:

=================================================================
==5239== ERROR: AddressSanitizer heap-buffer-overflow on address 0x7f1a6a4abf93 at pc 0x7f1a93bace23 bp 0x7fff827dfcc0 sp 0x7fff827dfcb8
READ of size 1 at 0x7f1a6a4abf93 thread T0
    #0 0x7f1a93bace23 (/home/attekett/src/objdir-ff-asan/toolkit/library/libxul.so+0x1d62e23)
0x7f1a6a4abf93 is located 3 bytes to the right of 16-byte region [0x7f1a6a4abf80,0x7f1a6a4abf90)
allocated by thread T0 here:
    #0 0x40a61e (/home/attekett/src/objdir-ff-asan/dist/bin/firefox+0x40a61e)
    #1 0x7f1a948f787c (/home/attekett/src/objdir-ff-asan/toolkit/library/libxul.so+0x2aad87c)
    #2 0x7f1a948f751d (/home/attekett/src/objdir-ff-asan/toolkit/library/libxul.so+0x2aad51d)
==5239== ABORTING
Stats: 371M malloced (276M for red zones) by 376415 calls
Stats: 220M realloced by 22961 calls
Stats: 346M freed by 260888 calls
Stats: 191M really freed by 217897 calls
Stats: 660M (169086 full pages) mmaped in 165 calls
  mmaps   by size class: 8:262128; 9:57337; 10:24570; 11:20470; 12:3072; 13:2048; 14:1792; 15:384; 16:960; 17:160; 18:112; 19:80; 20:132; 21:76; 22:1; 
  mallocs by size class: 8:274326; 9:53153; 10:21585; 11:18942; 12:2926; 13:1885; 14:1728; 15:397; 16:916; 17:160; 18:111; 19:76; 20:134; 21:75; 22:1; 
  frees   by size class: 8:174561; 9:43762; 10:18978; 11:16375; 12:2258; 13:1727; 14:1539; 15:341; 16:825; 17:148; 18:94; 19:73; 20:132; 21:74; 22:1; 
  rfrees  by size class: 8:141360; 9:39631; 10:16272; 11:15486; 12:1781; 13:911; 14:1470; 15:303; 16:323; 17:146; 18:50; 19:69; 20:95; 
Stats: malloc large: 557 small slow: 2256
Shadow byte and word:
  0x1fe34d4957f2: fb
  0x1fe34d4957f0: 00 00 fb fb fb fb fb fb
More shadow bytes:
  0x1fe34d4957d0: 00 fb fb fb fb fb fb fb
  0x1fe34d4957d8: fb fb fb fb fb fb fb fb
  0x1fe34d4957e0: fa fa fa fa fa fa fa fa
  0x1fe34d4957e8: fa fa fa fa fa fa fa fa
=>0x1fe34d4957f0: 00 00 fb fb fb fb fb fb
  0x1fe34d4957f8: fb fb fb fb fb fb fb fb
  0x1fe34d495800: fa fa fa fa fa fa fa fa
  0x1fe34d495808: fa fa fa fa fa fa fa fa
  0x1fe34d495810: fd fd fd fd fd fd fd fd

Not sure about the usage of asan_symbolize.py but from teh READ of size 1 I get this output:

=================================================================
==5239== ERROR: AddressSanitizer heap-buffer-overflow on address 0x7f1a6a4abf93 at pc 0x7f1a93bace23 bp 0x7fff827dfcc0 sp 0x7fff827dfcb8
READ of size 1 at 0x7f1a6a4abf93 thread T0
    #0 0x7f1a93bace23 in Convolve3x3 /home/attekett/src/content/svg/content/src/nsSVGFilters.cpp:4918
0x7f1a6a4abf93 is located 3 bytes to the right of 16-byte region [0x7f1a6a4abf80,0x7f1a6a4abf90)
allocated by thread T0 here:
    #0 0x40a61e in posix_memalign ??:0
    #1 0x7f1a948f787c in TryAllocAlignedBytes /home/attekett/src/gfx/thebes/gfxImageSurface.cpp:117
    #2 0x7f1a948f751d in gfxImageSurface::gfxImageSurface(nsIntSize const&, gfxASurface::gfxImageFormat) /home/attekett/src/gfx/thebes/gfxImageSurface.cpp:139
==5239== ABORTING
Stats: 371M malloced (276M for red zones) by 376415 calls
Stats: 220M realloced by 22961 calls
Stats: 346M freed by 260888 calls
Stats: 191M really freed by 217897 calls
Stats: 660M (169086 full pages) mmaped in 165 calls
  mmaps   by size class: 8:262128; 9:57337; 10:24570; 11:20470; 12:3072; 13:2048; 14:1792; 15:384; 16:960; 17:160; 18:112; 19:80; 20:132; 21:76; 22:1;
  mallocs by size class: 8:274326; 9:53153; 10:21585; 11:18942; 12:2926; 13:1885; 14:1728; 15:397; 16:916; 17:160; 18:111; 19:76; 20:134; 21:75; 22:1;
  frees   by size class: 8:174561; 9:43762; 10:18978; 11:16375; 12:2258; 13:1727; 14:1539; 15:341; 16:825; 17:148; 18:94; 19:73; 20:132; 21:74; 22:1;
  rfrees  by size class: 8:141360; 9:39631; 10:16272; 11:15486; 12:1781; 13:911; 14:1470; 15:303; 16:323; 17:146; 18:50; 19:69; 20:95;
Stats: malloc large: 557 small slow: 2256
Shadow byte and word:
  0x1fe34d4957f2: fb
  0x1fe34d4957f0: 00 00 fb fb fb fb fb fb
More shadow bytes:
  0x1fe34d4957d0: 00 fb fb fb fb fb fb fb
  0x1fe34d4957d8: fb fb fb fb fb fb fb fb
  0x1fe34d4957e0: fa fa fa fa fa fa fa fa
  0x1fe34d4957e8: fa fa fa fa fa fa fa fa
=>0x1fe34d4957f0: 00 00 fb fb fb fb fb fb
  0x1fe34d4957f8: fb fb fb fb fb fb fb fb
  0x1fe34d495800: fa fa fa fa fa fa fa fa
  0x1fe34d495808: fa fa fa fa fa fa fa fa
  0x1fe34d495810: fd fd fd fd fd fd fd fd

Comment 6

[Christian Holler (:decoder)]

(In reply to Atte Kettunen from comment #5)
> @Christian:
> 
> Before I reported this I built new ASAN build from the mozilla-central
> source at that time. I'm unable to reproduce the READ of size 4 with my
> current build. 
> 
> When I change the values from the repro-file into 
> 
> <g transform="matrix(100,-2562303,3000,100,300,300) "
> filter="url(#MyFilter)"/>
> 
> I can still get crash with report:

I will try your modified version on my build then :)

> 
> Not sure about the usage of asan_symbolize.py but from teh READ of size 1 I
> get this output:
> 
> =================================================================
> ==5239== ERROR: AddressSanitizer heap-buffer-overflow on address
> 0x7f1a6a4abf93 at pc 0x7f1a93bace23 bp 0x7fff827dfcc0 sp 0x7fff827dfcb8
> READ of size 1 at 0x7f1a6a4abf93 thread T0
>     #0 0x7f1a93bace23 in Convolve3x3


My first guess is that this is a duplicate to bug 711653 (the one you reported earlier). The symbolized trace in that bug shows the same crash signature. I'll try to confirm this though from my own builds first.

Comment 7

[Atte Kettunen]

(In reply to Christian Holler (:decoder) from comment #6)
> (In reply to Atte Kettunen from comment #5)
> > @Christian:
> > 
> > Before I reported this I built new ASAN build from the mozilla-central
> > source at that time. I'm unable to reproduce the READ of size 4 with my
> > current build. 
> > 
> > When I change the values from the repro-file into 
> > 
> > <g transform="matrix(100,-2562303,3000,100,300,300) "
> > filter="url(#MyFilter)"/>
> > 
> > I can still get crash with report:
> 
> I will try your modified version on my build then :)
> 
> > 
> > Not sure about the usage of asan_symbolize.py but from teh READ of size 1 I
> > get this output:
> > 
> > =================================================================
> > ==5239== ERROR: AddressSanitizer heap-buffer-overflow on address
> > 0x7f1a6a4abf93 at pc 0x7f1a93bace23 bp 0x7fff827dfcc0 sp 0x7fff827dfcb8
> > READ of size 1 at 0x7f1a6a4abf93 thread T0
> >     #0 0x7f1a93bace23 in Convolve3x3
> 
> 
> My first guess is that this is a duplicate to bug 711653 (the one you
> reported earlier). The symbolized trace in that bug shows the same crash
> signature. I'll try to confirm this though from my own builds first.

I was just checking the same thing about bug 711653. 

I have been building ASAN build with the instruction for the optimized build in https://developer.mozilla.org/en/Building_Firefox_with_Address_Sanitizer

Comment 8

[Christian Holler (:decoder)]

I was able to reproduce the crash using the modified testcase from comment 5 but it's a "heap-buffer-overflow" with "READ of size 1" and there is no stack that can be symbolized properly. It could be that the stack is corrupted at that point.

Because the other stack though was so close to that in bug 711653, I suggest we re-test this bug once the other has a fix so we can be sure it's a duplicate.

Comment 9

[Daniel Holbert [:dholbert]]

(In reply to Christian Holler (:decoder) from comment #8)
> Because the other stack though was so close to that in bug 711653, I suggest
> we re-test this bug once the other has a fix so we can be sure it's a
> duplicate.

FWIW, this doesn't fail the assertions in the debugging-patch that I just posted over on bug 711653 -- that may indicate that this has a different root cause. (or perhaps that my assertions are incorrect / insufficiently sensitive somehow)

Also: FWIW, this bug's testcase triggers this warning in my m-c debug build:
> WARNING: Surface size too large (would overflow)!: file ../../../mozilla/gfx/thebes/gfxASurface.cpp, line 383

The same applies to bug 724587, as I just noted in bug 724587 comment 3.  (that bug and this one may be dupes of each other.)

Comment 10

[Daniel Holbert [:dholbert]]

Still haven't been able to repro this on my machine (running w/ Valgrind now), but I was able to reproduce the similar bug 724587, and I've confirmed that they both take the early-return in longsonr's patch posted on bug 711653.

So, I suspect longsonr's patch on bug 724587 fixes this, but I'll need help from someone who can repro to confirm that.

Comment 11

[Daniel Holbert [:dholbert]]

(In reply to Daniel Holbert [:dholbert] from comment #10)
> So, I suspect longsonr's patch on bug 724587 fixes this, but I'll need help
> from someone who can repro to confirm that.

er "on bug 711653" (copypaste failure).  Sorry for the bug number soup.

Comment 12

[Daniel Holbert [:dholbert]]

Attachment: testcase modified per comment 5 (reproduces bug)

(In reply to Daniel Holbert [:dholbert] from comment #10)
> Still haven't been able to repro this on my machine (running w/ Valgrind

decoder pointed out to me that I need to make the modification in comment 5 in order to reproduce this (or at least, he needed that tweak).

With that modified testcase (attached here for convenience), I can repro this in valgrind, and I can confirm that longsonr's patch on bug 711653 fixes it.

We get calls to GenerateNormal with surfaceWidth=1 surfaceHeight=4, which triggers the new early-return and saves us from the UMR.

Comment 13

[Christian Holler (:decoder)]

Confirmed that the patch from bug 711653 fixes the ASan error of the testcase (as per comment 12)

Comment 14

[Daniel Holbert [:dholbert]]

Thanks! Duping.

Comment 15

[Daniel Holbert [:dholbert]]

Landed the modified testcase ( attachment 596857 [details] ) as a crashtest:
  https://hg.mozilla.org/integration/mozilla-inbound/rev/5b3cf801e0e0

Comment 16

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/mozilla-central/rev/5b3cf801e0e0