Closed
Bug 1815737
Opened 3 years ago
Closed 3 years ago
Update libjpeg-turbo to 2.1.5.1
Categories
(Core :: Graphics: ImageLib, task)
Core
Graphics: ImageLib
Tracking
()
RESOLVED
FIXED
111 Branch
| Tracking | Status | |
|---|---|---|
| firefox111 | --- | fixed |
People
(Reporter: RyanVM, Assigned: RyanVM)
References
Details
Attachments
(1 file)
+++ This bug was initially created as a clone of Bug #1787515 +++
https://github.com/libjpeg-turbo/libjpeg-turbo/releases/tag/2.1.5
https://github.com/libjpeg-turbo/libjpeg-turbo/releases/tag/2.1.5.1
2.1.5
Significant changes relative to 2.1.4:
- Fixed issues in the build system whereby, when using the Ninja Multi-Config CMake generator, a static build of libjpeg-turbo (a build in which ENABLE_SHARED is 0) could not be installed, a Windows installer could not be built, and the Java regression tests failed.
- Fixed a regression introduced by 2.0 beta1[15] that caused a buffer overrun in the progressive Huffman encoder when attempting to transform a specially-crafted malformed 12-bit-per-component JPEG image into a progressive 12-bit-per-component JPEG image using a 12-bit-per-component build of libjpeg-turbo (-DWITH_12BIT=1.) Given that the buffer overrun was fully contained within the progressive Huffman encoder structure and did not cause a segfault or other user-visible errant behavior, given that the lossless transformer (unlike the decompressor) is not generally exposed to arbitrary data exploits, and given that 12-bit-per-component builds of libjpeg-turbo are uncommon, this issue did not likely pose a security risk.
- Fixed an issue whereby, when using a 12-bit-per-component build of libjpeg-turbo (-DWITH_12BIT=1), passing samples with values greater than 4095 or less than 0 to jpeg_write_scanlines() caused a buffer overrun or underrun in the RGB-to-YCbCr color converter.
- Fixed a floating point exception that occurred when attempting to use the jpegtran -drop and -trim options to losslessly transform a specially-crafted malformed JPEG image.
- Fixed an issue in tjBufSizeYUV2() whereby it returned a bogus result, rather than throwing an error, if the align parameter was not a power of 2. Fixed a similar issue in tjCompressFromYUV() whereby it generated a corrupt JPEG image in certain cases, rather than throwing an error, if the align parameter was not a power of 2.
- Fixed an issue whereby tjDecompressToYUV2(), which is a wrapper for tjDecompressToYUVPlanes(), used the desired YUV image dimensions rather than the actual scaled image dimensions when computing the plane pointers and strides to pass to tjDecompressToYUVPlanes(). This caused a buffer overrun and subsequent segfault if the desired image dimensions exceeded the scaled image dimensions.
- Fixed an issue whereby, when decompressing a 12-bit-per-component JPEG image (-DWITH_12BIT=1) using an alpha-enabled output color space such as JCS_EXT_RGBA, the alpha channel was set to 255 rather than 4095.
- Fixed an issue whereby the Java version of TJBench did not accept a range of quality values.
- Fixed an issue whereby, when -progressive was passed to TJBench, the JPEG input image was not transformed into a progressive JPEG image prior to decompression.
2.1.5.1
Significant changes relative to 2.1.5:
- The SIMD dispatchers in libjpeg-turbo 2.1.4 and prior stored the list of supported SIMD instruction sets in a global variable, which caused an innocuous race condition whereby the variable could have been initialized multiple times if jpeg_start_compress() was called simultaneously in multiple threads. libjpeg-turbo 2.1.5 included an undocumented attempt to fix this race condition by making the SIMD support variable thread-local. However, that caused another issue whereby, if jpeg_start_compress() was called in one thread and jpeg_read_() or jpeg_write_() was called in a second thread, the SIMD support variable was never initialized in the second thread. On x86 systems, this led the second thread to incorrectly assume that AVX2 instructions were always available, and when it attempted to use those instructions on older x86 CPUs that do not support them, an illegal instruction error occurred. The SIMD dispatchers now ensure that the SIMD support variable is initialized before dispatching based on its value.
| Assignee | ||
Comment 1•3 years ago
|
||
Try push:
https://treeherder.mozilla.org/jobs?repo=try&revision=efe24b40fb92d6b85021aaed2e0953414fdf49bb
Assignee: nobody → ryanvm
| Assignee | ||
Comment 2•3 years ago
|
||
Pushed by rvandermeulen@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/c7e43d4332a5
Update libjpeg-turbo to 2.1.5.1. r=aosmond
Comment 4•3 years ago
|
||
| bugherder | ||
Status: NEW → RESOLVED
Closed: 3 years ago
status-firefox111:
--- → fixed
Resolution: --- → FIXED
Target Milestone: --- → 111 Branch
You need to log in
before you can comment on or make changes to this bug.
Description
•