1542821 - Tab crash on this image (which contains errors) on Windows-on-ARM builds (but not on Intel)

Status: RESOLVED DUPLICATE of bug 1542827

(Core :: Graphics: ImageLib, defect, P2)

Description

[Andrew Overholt [:overholt]]

https://phonebook.mozilla.org/pic.php?mail=[e-mail]&type=thumb

I'm marking this bug as MoCo-confidential because it's Dan's phonebook photo. Dan, what do you think: should we keep this confidential or copy your image somewhere else? Maybe Andrew Osmond will know how to make a non-dveditz's-photo image that reproduces the situation and we can file a different, public bug for that.

Comment 1

[Andrew Overholt [:overholt]]

(Apparently you can't set needinfo when filing a bug)

Comment 2

[Andrew Overholt [:overholt]]

Nicolas managed to reproduce the crash and https://crash-stats.mozilla.org/report/index/7ad7cdcb-389a-4f5d-9f2f-6def90190408 has a crash address which matches the jemalloc poison value.

Comment 3

[Andrew Osmond [:aosmond] (he/him)]

Looks like it is failing to longjmp:

Child-SP RetAddr Call Site

00 000000726927e380 00007ffb416f1e88 ntdll!RtlRaiseStatus+0x1c
01 000000726927e7d0 00007ffb416c899c ntdll!wcstok_s+0x13328
02 000000726927ede0 00007ffb382a2a20 ntdll!RtlUnwind+0x1c
*** ERROR: Symbol file could not be found. Defaulted to export symbols for C:\WINDOWS\SYSTEM32\VCRUNTIME140.dll -
03 000000726927f190 00007ffb382a1c54 VCRUNTIME140!local_unwind+0x80
04 000000726927f240 00007ffb04ac725c VCRUNTIME140!longjmp+0x24
05 000000726927f260 00007ffb06a90a14 xul!mozilla::image::my_error_exit+0x30 [z:\task_1554720275\build\src\image\decoders\nsJPEGDecoder.cpp @ 758]
06 000000726927f270 0000000000000000 xul!read_markers+0xf8 [z:\task_1554720275\build\src\media\libjpeg\jdmarker.c @ 977]

Comment 4

[Daniel Veditz [:dveditz]]

What happened to my photo? Used to display fine. Did someone re-encode it? (on desktop I get a message about the image having errors).

Feel free to use that image. IIRC it's the same image I use for gravatar and my twitter photo so it's public already.

Comment 5

[Daniel Veditz [:dveditz]]

The crash in comment 2 is a security bug though, so maybe keep it confidential on that grounds.

Comment 6

[Andrew Osmond [:aosmond] (he/him)]

We have a gtest, ImageDecoders.CorruptSingleChunk, written which tries to decode a corrupt JPEG, and said image reproduces the same crash: https://searchfox.org/mozilla-central/source/image/test/gtest/corrupt.jpg

dmajor, any ideas on why this longjmp is failing?

https://searchfox.org/mozilla-central/rev/6db0a6a56653355fcbb25c4fa79c6e7ffc6f88e9/image/decoders/nsJPEGDecoder.cpp#758

Comment 7

[Daniel Veditz [:dveditz]]

Attachment: phonebook.jpg

Capturing the image here because I will likely want a working phonebook picture before we stop wanting a testcase for this bug.

Comment 8

[Christian Holler (:decoder)]

Fwiw, I ran the corrupt.jpg file from gtests on the Linux jpeg fuzzing target on native ARM64 hardware and could not reproduce the crash.

Comment 9

[Gabriele Svelto [:gsvelto]]

(In reply to Andrew Overholt [:overholt] from comment #2)

Nicolas managed to reproduce the crash and https://crash-stats.mozilla.org/report/index/7ad7cdcb-389a-4f5d-9f2f-6def90190408 has a crash address which matches the jemalloc poison value.

Note that the crash reason in that report is EXCEPTION_DATATYPE_MISALIGNMENT, so we've loaded the poison value from somewhere - presumably the 'mMonitor' field - and we're trying to use it as a pointer. We should get an illegal access here but since this is happening within locking code it's probably using an atomic access which requires natural alignment (e.g. LDXR) and triggers the alignment exception. That being said I can't fathom how image decoding can lead to a crash in the IPC code; I've got a local debug build with crash reporting enabled so I can try to repro tomorrow.

Comment 10

[(Away)]

(In reply to Andrew Osmond [:aosmond] from comment #6)

We have a gtest, ImageDecoders.CorruptSingleChunk, written which tries to
decode a corrupt JPEG, and said image reproduces the same crash:
https://searchfox.org/mozilla-central/source/image/test/gtest/corrupt.jpg

dmajor, any ideas on why this longjmp is failing?

https://searchfox.org/mozilla-central/rev/
6db0a6a56653355fcbb25c4fa79c6e7ffc6f88e9/image/decoders/nsJPEGDecoder.cpp#758

In my debugger I can see that err has been poisoned, so the setjmp_buffer is full of corrupted values. I'm guessing Windows does some sanity checks before doing the jmp, and we failed them.

Comment 11

[Andrew Osmond [:aosmond] (he/him)]

Testing with more recent builds today, I found it got fixed. mozregression says bug 1542827 which makes sense.