1607379 - Update libjpeg-turbo to 2.0.4

Status: RESOLVED FIXED

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

Description

[Ryan VanderMeulen [:RyanVM]]

Not a lot of relevant changes from 2.0.3 (most of the changes were TurboJPEG-related, which we don't ship in Firefox), but the ARM64 changes might be useful. The patch is kinda big due to various code cleanups also included, however.

Significant changes relative to 2.0.3:

• Fixed a regression in the Windows packaging system (introduced by 2.0 beta1[2]) whereby, if both the 64-bit libjpeg-turbo SDK for GCC and the 64-bit libjpeg-turbo SDK for Visual C++ were installed on the same system, only one of them could be uninstalled.
• Fixed a signed integer overflow and subsequent segfault that occurred when attempting to decompress images with more than 715827882 pixels using the 64-bit C version of TJBench.
• Fixed out-of-bounds write in tjDecompressToYUV2() and tjDecompressToYUVPlanes() (sometimes manifesting as a double free) that occurred when attempting to decompress grayscale JPEG images that were compressed with a sampling factor other than 1 (for instance, with cjpeg -grayscale -sample 2x2).
• Fixed a regression introduced by 2.0.2[5] that caused the TurboJPEG API to incorrectly identify some JPEG images with unusual sampling factors as 4:4:4 JPEG images. This was known to cause a buffer overflow when attempting to decompress some such images using tjDecompressToYUV2() or tjDecompressToYUVPlanes().
• Fixed an issue, detected by ASan, whereby attempting to losslessly transform a specially-crafted malformed JPEG image containing an extremely-high-frequency coefficient block (junk image data that could never be generated by a legitimate JPEG compressor) could cause the Huffman encoder's local buffer to be overrun. (Refer to 1.4.0[9] and 1.4beta1[15].) Given that the buffer overrun was fully contained within the stack and did not cause a segfault or other user-visible errant behavior, and given that the lossless transformer (unlike the decompressor) is not generally exposed to arbitrary data exploits, this issue did not likely pose a security risk.
• The ARM 64-bit (ARMv8) NEON SIMD assembly code now stores constants in a separate read-only data section rather than in the text section, to support execute-only memory layouts.

Green on Try:
https://treeherder.mozilla.org/#/jobs?repo=try&revision=3879b36bca0651d971a428b80b66d209eb14a5ef

Comment 1

[Ryan VanderMeulen [:RyanVM]]

Attachment: Bug 1607379 - Update libjpeg-turbo to 2.0.4. r=aosmond

Comment 2

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/fdf431b70541
Update libjpeg-turbo to 2.0.4. r=aosmond

Comment 3

[Raul Gurzau (:RaulG)]

https://hg.mozilla.org/mozilla-central/rev/fdf431b70541