1304537 - Update libjpeg-turbo to version 1.5.1

Status: RESOLVED FIXED

(Core :: Graphics: ImageLib, defect)

Description

[Ryan VanderMeulen [:RyanVM]]

https://github.com/libjpeg-turbo/libjpeg-turbo/releases/tag/1.5.1

Official binaries and source tarball are available at:
https://sourceforge.net/projects/libjpeg-turbo/files/1.5.1/

Significant changes relative to 1.5.0:

* Previously, the undocumented JSIMD_FORCE* environment variables could be used to force-enable a particular SIMD instruction set if multiple instruction sets were available on a particular platform. On x86 platforms, where CPU feature detection is bulletproof and multiple SIMD instruction sets are available, it makes sense for those environment variables to allow forcing the use of an instruction set only if that instruction set is available. However, since the ARM implementations of libjpeg-turbo can only use one SIMD instruction set, and since their feature detection code is less bulletproof (parsing /proc/cpuinfo), it makes sense for the JSIMD_FORCENEON environment variable to bypass the feature detection code and really force the use of NEON instructions. A new environment variable (JSIMD_FORCEDSPR2) was introduced in the MIPS implementation for the same reasons, and the existing JSIMD_FORCENONE environment variable was extended to that implementation. These environment variables provide a workaround for those attempting to test ARM and MIPS builds of libjpeg-turbo in QEMU, which passes through /proc/cpuinfo from the host system.

* libjpeg-turbo previously assumed that AltiVec instructions were always available on PowerPC platforms, which led to "illegal instruction" errors when running on PowerPC chips that lack AltiVec support (such as the older 7xx/G3 and newer e5500 series.) libjpeg-turbo now examines /proc/cpuinfo on Linux/Android systems and enables AltiVec instructions only if the CPU supports them. It also now provides two environment variables, JSIMD_FORCEALTIVEC and JSIMD_FORCENONE, to force-enable and force-disable AltiVec instructions in environments where /proc/cpuinfo is an unreliable means of CPU feature detection (such as when running in QEMU.) On OS X, libjpeg-turbo continues to assume that AltiVec support is always available, which means that libjpeg-turbo cannot be used with G3 Macs unless you set the environment variable JSIMD_FORCENONE to 1.

* Fixed an issue whereby 64-bit ARM (AArch64) builds of libjpeg-turbo would crash when built with recent releases of the Clang/LLVM compiler. This was caused by an ABI conformance issue in some of libjpeg-turbo's 64-bit NEON SIMD routines. Those routines were incorrectly using 64-bit instructions to transfer a 32-bit JDIMENSION argument, whereas the ABI allows the upper (unused) 32 bits of a 32-bit argument's register to be undefined. The new Clang/LLVM optimizer uses load combining to transfer multiple adjacent 32-bit structure members into a single 64-bit register, and this exposed the ABI conformance issue.

* Fancy upsampling is now supported when decompressing JPEG images that use 4:4:0 (h1v2) chroma subsampling. These images are generated when losslessly rotating or transposing JPEG images that use 4:2:2 (h2v1) chroma subsampling. The h1v2 fancy upsampling algorithm is not currently SIMD-accelerated.

* If merged upsampling isn't SIMD-accelerated but YCbCr-to-RGB conversion is, then libjpeg-turbo will now disable merged upsampling when decompressing YCbCr JPEG images into RGB or extended RGB output images. This significantly speeds up the decompression of 4:2:0 and 4:2:2 JPEGs on ARM platforms if fancy upsampling is not used (for example, if the -nosmooth option to djpeg is specified.)

* The TurboJPEG API will now decompress 4:2:2 and 4:4:0 JPEG images with 2x2 luminance sampling factors and 2x1 or 1x2 chrominance sampling factors. This is a non-standard way of specifying 2x subsampling (normally 4:2:2 JPEGs have 2x1 luminance and 1x1 chrominance sampling factors, and 4:4:0 JPEGs have 1x2 luminance and 1x1 chrominance sampling factors), but the JPEG specification and the libjpeg API both allow it.

* Fixed an unsigned integer overflow in the libjpeg memory manager, detected by the Clang undefined behavior sanitizer, that could be triggered by attempting to decompress a specially-crafted malformed JPEG image. This issue affected only 32-bit code and did not pose a security threat, but removing the warning makes it easier to detect actual security issues, should they arise in the future.

* Fixed additional negative left shifts and other issues reported by the GCC and Clang undefined behavior sanitizers when attempting to decompress specially-crafted malformed JPEG images. None of these issues posed a security threat, but removing the warnings makes it easier to detect actual security issues, should they arise in the future.

* Fixed an out-of-bounds array reference, introduced by 1.4.902 and detected by the Clang undefined behavior sanitizer, that could be triggered by a specially-crafted malformed JPEG image with more than four components. Because the out-of-bounds reference was still within the same structure, it was not known to pose a security threat, but removing the warning makes it easier to detect actual security issues, should they arise in the future.

* Fixed another ABI conformance issue in the 64-bit ARM (AArch64) NEON SIMD code. Some of the routines were incorrectly reading and storing data below the stack pointer, which caused segfaults in certain applications under specific circumstances.

Comment 1

[Ryan VanderMeulen [:RyanVM]]

This fixes some regressions in 1.5.0 that look important, especially the UBSan fixes. I think we should consider this for uplift.

Comment 2

[Ryan VanderMeulen [:RyanVM]]

Attachment: update libjpeg-turbo to version 1.5.1

https://treeherder.mozilla.org/#/jobs?repo=try&revision=66b9fb012f66

Comment 3

[Ryan VanderMeulen [:RyanVM]]

Attachment: update libjpeg-turbo to version 1.5.1

Previous patch had Android bustage. Fixed in the new patch and upstream bug filed.

https://treeherder.mozilla.org/#/jobs?repo=try&revision=62e69b0abeaf&noautoclassify&group_state=expanded

Comment 4

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/mozilla-inbound/rev/84b1456a0556
Update libjpeg-turbo to version 1.5.1. r=jrmuizel

Comment 5

[Carsten Book [:Tomcat]]

https://hg.mozilla.org/mozilla-central/rev/84b1456a0556

Comment 6

[Carsten Book [:Tomcat]]

https://hg.mozilla.org/mozilla-central/rev/84b1456a0556

Comment 7

[Ryan VanderMeulen [:RyanVM]]

Comment on attachment 8793606 [details] [diff] [review]
update libjpeg-turbo to version 1.5.1

Approval Request Comment
[Feature/regressing bug #]: bug 1278648
[User impact if declined]: Some malformed JPEGs could cause trouble (see deps)
[Describe test coverage new/current, TreeHerder]: We have automated image decoding tests and JPEG is widely-used enough that I'm sure we'd have heard if there were real-world issues since this landed a week ago :)
[Risks and why]: Not very big. Just cleans up some undefined behavior in edge case scenarios.
[String/UUID change made/needed]: None

Comment 8

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

Comment on attachment 8793606 [details] [diff] [review]
update libjpeg-turbo to version 1.5.1

This has stabilized on Nightly52 for a week, libupdates like are business as usual I've been told, Aurora51+, Beta50+

Comment 9

[Ryan VanderMeulen [:RyanVM]]

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

Comment 10

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/releases/mozilla-beta/rev/317ad66705b6