Opening the attached page causes a heap buffer overflow to occur. Tested in current and a few older tinderbox asan builds in 64-bit Linux. ==30750==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x60300009167c at pc 0x7fb955beda11 bp 0x7fb93a9f0cc0 sp 0x7fb93a9f0cb8 READ of size 4 at 0x60300009167c thread T18 (ImgDecoder #1) #0 0x7fb955beda10 in GetFilterOffsetAndLength /builds/slave/m-cen-l64-asan-000000000000000/build/src/gfx/2d/convolver.h:120 #1 0x7fb955beda10 in CommitRow /builds/slave/m-cen-l64-asan-000000000000000/build/src/image/Downscaler.cpp:170 #2 0x7fb955c55beb in OutputScanlines /builds/slave/m-cen-l64-asan-000000000000000/build/src/image/decoders/nsJPEGDecoder.cpp:627 #3 0x7fb955c54291 in WriteInternal /builds/slave/m-cen-l64-asan-000000000000000/build/src/image/decoders/nsJPEGDecoder.cpp:501 #4 0x7fb955be9242 in Write /builds/slave/m-cen-l64-asan-000000000000000/build/src/image/Decoder.cpp:183 #5 0x7fb955be74fc in Decode /builds/slave/m-cen-l64-asan-000000000000000/build/src/image/Decoder.cpp:128 #6 0x7fb955be6f22 in Decode /builds/slave/m-cen-l64-asan-000000000000000/build/src/image/DecodePool.cpp:453 #7 0x7fb955c097cc in Run /builds/slave/m-cen-l64-asan-000000000000000/build/src/image/DecodePool.cpp:282 #8 0x7fb953bc8fef in ProcessNextEvent /builds/slave/m-cen-l64-asan-000000000000000/build/src/xpcom/threads/nsThread.cpp:960 #9 0x7fb953c420aa in NS_ProcessNextEvent /builds/slave/m-cen-l64-asan-000000000000000/build/src/xpcom/glue/nsThreadUtils.cpp:277 #10 0x7fb9544dd57f in Run /builds/slave/m-cen-l64-asan-000000000000000/build/src/ipc/glue/MessagePump.cpp:326 #11 0x7fb95444a4fc in RunInternal /builds/slave/m-cen-l64-asan-000000000000000/build/src/ipc/chromium/src/base/message_loop.cc:234 #12 0x7fb95444a4fc in RunHandler /builds/slave/m-cen-l64-asan-000000000000000/build/src/ipc/chromium/src/base/message_loop.cc:227 #13 0x7fb95444a4fc in Run /builds/slave/m-cen-l64-asan-000000000000000/build/src/ipc/chromium/src/base/message_loop.cc:201 #14 0x7fb953bc4d60 in ThreadFunc /builds/slave/m-cen-l64-asan-000000000000000/build/src/xpcom/threads/nsThread.cpp:382 #15 0x7fb9610074b5 in _pt_root /builds/slave/m-cen-l64-asan-000000000000000/build/src/nsprpub/pr/src/pthreads/ptthread.c:212 #16 0x7fb961646181 in start_thread /build/buildd/eglibc-2.19/nptl/pthread_create.c:312 (discriminator 2) #17 0x7fb95165847c in clone /build/buildd/eglibc-2.19/misc/../sysdeps/unix/sysv/linux/x86_64/clone.S:111 [...]

Alternatively you can use this image, but still need dimensions from the image tag.

Seth, is this related to one of the other heap overrun issues you fixed recently?

Doubtful at this point. Those were decoder-specific issues in a different decoder.

A test with gif images triggered the same trace. Seems to be at least somewhat decoder-independent. Let me know if you need other testcases.

Kamil: can you run these testcases in an ASAN build and see if it still repros. If so attach the logs (two different testcases). Thanks.

@dveditz Oops, I wasn't clear on the instructions. Some pictures trigger the bug when they are drawn with specific dimensions. ff-bofr-getfilter.html has one such jpg as a data uri, and you can also trigger the bug by including ff-bofr-getfilter.jpg (which is the same image) in the same tag.

Used the following build to reproduce the issue: - http://inbound-archive.pub.build.mozilla.org/pub/mozilla.org/firefox/tinderbox-builds/mozilla-central-linux64-asan/1445378439/ Reproduced the crash several times with the .html that has been attached and the .jpg image via: * <img src="ff-bofr-getfilter.jpg" width="3px" height="2px"> As per comment #6, the image is the same so you'll get the same crash for both test cases on e10s and non-e10s. ================================================================= ==2370== ERROR: AddressSanitizer: heap-buffer-overflow on address 0x6030000fa0dc at pc 0x7fb3bd418a7c bp 0x7fb3a01e9c80 sp 0x7fb3a01e9c78 READ of size 4 at 0x6030000fa0dc thread T19 (ImgDecoder #2) #0 0x7fb3bd418a7b in GetFilterOffsetAndLength convolver.h:120 #1 0x7fb3bd488142 in OutputScanlines nsJPEGDecoder.cpp:627 #2 0x7fb3bd486781 in WriteInternal nsJPEGDecoder.cpp:501 #3 0x7fb3bd414ad2 in Write Decoder.cpp:183 #4 0x7fb3bd412d8c in Decode Decoder.cpp:128 #5 0x7fb3bd4127b2 in Decode DecodePool.cpp:453 #6 0x7fb3bd43139c in Run DecodePool.cpp:282 #7 0x7fb3bb454f0f in ProcessNextEvent nsThread.cpp:972 #8 0x7fb3bb4ce2ea in NS_ProcessNextEvent nsThreadUtils.cpp:297 #9 0x7fb3bbd7a83f in Run MessagePump.cpp:326 #10 0x7fb3bbce7e8c in RunInternal message_loop.cc:234 #11 0x7fb3bb450c20 in ThreadFunc nsThread.cpp:384 #12 0x7fb3c89f34b5 in _pt_root ptthread.c:212 #13 0x7fb3c9032181 in start_thread pthread_create.c:312 (discriminator 2) #14 0x7fb3b8e9a47c in clone clone.S:111 0x6030000fa0dc is located 4 bytes to the right of 24-byte region [0x6030000fa0c0,0x6030000fa0d8) allocated by thread T19 (ImgDecoder #2) here: #0 0x4750b1 in __interceptor_malloc _asan_rtl_ #1 0x48dd5d in moz_xmalloc mozalloc.cpp:83 #2 0x7fb3bceb9bc9 in operator new mozalloc.h:186 #3 0x7fb3bceb696f in push_back stl_vector.h:891 #4 0x7fb3bcdcea73 in ComputeFilters image_operations.cpp:151 #5 0x7fb3bd4193a5 in BeginFrame Downscaler.cpp:102 #6 0x7fb3bd485d55 in WriteInternal nsJPEGDecoder.cpp:401 #7 0x7fb3bd414ad2 in Write Decoder.cpp:183 #8 0x7fb3bd412d8c in Decode Decoder.cpp:128 #9 0x7fb3bd4127b2 in Decode DecodePool.cpp:453 #10 0x7fb3bd43139c in Run DecodePool.cpp:282 #11 0x7fb3bb454f0f in ProcessNextEvent nsThread.cpp:972 #12 0x7fb3bb4ce2ea in NS_ProcessNextEvent nsThreadUtils.cpp:297 #13 0x7fb3bbd7a83f in Run MessagePump.cpp:326 #14 0x7fb3bbce7e8c in RunInternal message_loop.cc:234 #15 0x7fb3bb450c20 in ThreadFunc nsThread.cpp:384 #16 0x7fb3c89f34b5 in _pt_root ptthread.c:212 #17 0x7fb3c9032181 in start_thread pthread_create.c:312 (discriminator 2) Thread T19 (ImgDecoder #2) created by T0 (Web Content) here: #0 0x461925 in __interceptor_pthread_create _asan_rtl_ #1 0x7fb3c89efe3d in _PR_CreateThread ptthread.c:453 #2 0x7fb3c89ef9ba in PR_CreateThread ptthread.c:544 #3 0x7fb3bb45235d in Init nsThread.cpp:504 #4 0x7fb3bb4587de in NewThread nsThreadManager.cpp:249 #5 0x7fb3bb4cd578 in NS_NewThread nsThreadUtils.cpp:71 #6 0x7fb3bd411311 in DecodePool DecodePool.cpp:355 #7 0x7fb3bd410b1b in Singleton DecodePool.cpp:315 #8 0x7fb3bd461c38 in InitModule nsImageModule.cpp:95 #9 0x7fb3bb42701d in Load nsComponentManager.cpp:886 #10 0x7fb3bb428271 in CreateInstanceByContractID nsComponentManager.cpp:1220 #11 0x7fb3bb41f884 in GetServiceByContractID nsComponentManager.cpp:1579 #12 0x7fb3bb4bd7e1 in CallGetService nsComponentManagerUtils.cpp:67 #13 0x7fb3bb4b2406 in assign_from_gs_contractid nsCOMPtr.cpp:103 #14 0x7fb3bd2a87f5 in nsCOMPtr nsCOMPtr.h:540 #15 0x7fb3bd2a6b44 in GetPlatform gfxPlatform.cpp:455 #16 0x7fb3c078cee3 in Init ContentProcess.cpp:83 #17 0x7fb3c2c1e5a0 in XRE_InitChildProcess nsEmbedFunctions.cpp:601 #18 0x48d740 in content_process_main plugin-container.cpp:237 #19 0x7fb3b8dc1ec4 in __libc_start_main libc-start.c:287 SUMMARY: AddressSanitizer: heap-buffer-overflow ??:0 ?? Shadow bytes around the buggy address: 0x0c06800173c0: 00 03 fa fa 00 00 00 03 fa fa 00 00 00 03 fa fa 0x0c06800173d0: 00 00 00 03 fa fa 00 00 00 03 fa fa 00 00 00 03 0x0c06800173e0: fa fa 00 00 00 03 fa fa 00 00 00 03 fa fa 00 00 0x0c06800173f0: 00 03 fa fa 00 00 00 03 fa fa 00 00 00 03 fa fa 0x0c0680017400: 00 00 00 03 fa fa 00 00 00 03 fa fa 00 00 00 03 =>0x0c0680017410: fa fa 00 00 00 03 fa fa 00 00 00[fa]fa fa fd fd 0x0c0680017420: fd fd fa fa fd fd fd fa fa fa fd fd fd fd fa fa 0x0c0680017430: 00 00 00 fa fa fa 00 00 00 fa fa fa fd fd fd fd 0x0c0680017440: fa fa fd fd fd fa fa fa fd fd fd fa fa fa fd fd 0x0c0680017450: fd fd fa fa fd fd fd fd fa fa fd fd fd fa fa fa 0x0c0680017460: fd fd fd fa fa fa fd fd fd fd fa fa fd fd fd 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 =2370==ABORTING

Seth, can you suggest a security rating for this issue? Who can we get to take a look at making a patch for this?

Another image type to trigger this with. Open via <img src="row.gif" height="1px"> to reproduce.

These testcases strongly remind me of bug 1224200 and I could see them triggering the same problem (very large image downscaled to very small size). I couldn't reproduce a crash without the patch for bug 1224200 though, so I can't be sure. If someone who would reproduce wants to try now that the patches for bug 1224200 we could maybe this close bug.

Reproduced the original issue using the following build: * https://archive.mozilla.org/pub/firefox/tinderbox-builds/mozilla-central-linux64-asan/1445378439/ Went through verification using the following build: * https://archive.mozilla.org/pub/firefox/tinderbox-builds/mozilla-central-linux64-asan/1453414712/ Looks like this has been fixed. I can't reproduce the crash using both test cases with the latest asan build.. However, I'm seeing the following when opening "ff-bofr-getfilter.jpg" via <img src="ff-bofr-getfilter.jpg" width="3px" height="2px"> (not sure if this is an issue): > (process:4003): GLib-CRITICAL **: g_path_get_basename: assertion 'file_name != NULL' failed > Corrupt JPEG data: 5 extraneous bytes before marker 0xdb > Corrupt JPEG data: 5 extraneous bytes before marker 0xdb > Corrupt JPEG data: 5 extraneous bytes before marker 0xdb > Corrupt JPEG data: 5 extraneous bytes before marker 0xdb > Corrupt JPEG data: 5 extraneous bytes before marker 0xdb > Corrupt JPEG data: 5 extraneous bytes before marker 0xdb > Corrupt JPEG data: 5 extraneous bytes before marker 0xdb > Corrupt JPEG data: 5 extraneous bytes before marker 0xdb > Corrupt JPEG data: 5 extraneous bytes before marker 0xdb > Corrupt JPEG data: 5 extraneous bytes before marker 0xdb STR: * opened "ff-bofr-getfilter.jpg" via <img src="ff-bofr-getfilter.jpg" width="3px" height="2px"> * opened "row.gif" via <img src="row.gif" height="1px"> Test Cases Used: * opened each of the test cases above 10 different times in new tabs via a e10s window without crashes * opened each of the test cases above 10 different times in new tabs via a non-e10s window without crashes * opened each of the test cases above 10 different times in new tabs via a private browsing window without crashes

(In reply to Kamil Jozwiak [:kjozwiak] from comment #11) > Looks like this has been fixed. I can't reproduce the crash using both test > cases with the latest asan build.. However, I'm seeing the following when > opening "ff-bofr-getfilter.jpg" via <img src="ff-bofr-getfilter.jpg" > width="3px" height="2px"> (not sure if this is an issue): > > > (process:4003): GLib-CRITICAL **: g_path_get_basename: assertion 'file_name != NULL' failed > > Corrupt JPEG data: 5 extraneous bytes before marker 0xdb > > Corrupt JPEG data: 5 extraneous bytes before marker 0xdb > > Corrupt JPEG data: 5 extraneous bytes before marker 0xdb > > Corrupt JPEG data: 5 extraneous bytes before marker 0xdb > > Corrupt JPEG data: 5 extraneous bytes before marker 0xdb > > Corrupt JPEG data: 5 extraneous bytes before marker 0xdb > > Corrupt JPEG data: 5 extraneous bytes before marker 0xdb > > Corrupt JPEG data: 5 extraneous bytes before marker 0xdb > > Corrupt JPEG data: 5 extraneous bytes before marker 0xdb > > Corrupt JPEG data: 5 extraneous bytes before marker 0xdb Thanks for verifying! I don't think that is an issue.