Releases: libjpeg-turbo/libjpeg-turbo
2.0.4
Assets
- libjpeg-turbo-2.0.4.tar.gz is the official source tarball for this release. The automatically generated "Source code" assets are not supported.
- Refer to https://libjpeg-turbo.org/Downloads/DigitalSignatures for information regarding the methods used to sign the files in this release and instructions for verifying the signatures.
- Refer to https://libjpeg-turbo.org/Documentation/OfficialBinaries for information regarding the compatibility of the binary packages in this release.
Support
Code Quality: Stable
Current Support Category: Extended
Release Notes
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()
andtjDecompressToYUVPlanes()
(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, withcjpeg -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()
ortjDecompressToYUVPlanes()
. -
Fixed an issue (CVE-2020-17541), 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.
2.0.3
Assets
- libjpeg-turbo-2.0.3.tar.gz is the official source tarball for this release. The automatically generated "Source code" assets are not supported.
- Refer to https://libjpeg-turbo.org/Downloads/DigitalSignatures for information regarding the methods used to sign the files in this release and instructions for verifying the signatures.
- Refer to https://libjpeg-turbo.org/Documentation/OfficialBinaries for information regarding the compatibility of the binary packages in this release.
Packaging Changes
- Fixed a regression introduced in libjpeg-turbo 2.0.1 whereby the libjpeg-turbo static libraries (libjpeg.a and libturbojpeg.a) could not be used with MinGW GCC v4-v6 toolchains.
Support
Code Quality: Stable
Current Support Category: Extended
Release Notes
Significant changes relative to 2.0.2:
-
Fixed "using JNI after critical get" errors that occurred on Android platforms when passing invalid arguments to certain methods in the TurboJPEG Java API.
-
Fixed a regression in the SIMD feature detection code, introduced by the AVX2 SIMD extensions (2.0 beta1[1]), that was known to cause an illegal instruction exception, in rare cases, on CPUs that lack support for CPUID leaf 07H (or on which the maximum CPUID leaf has been limited by way of a BIOS setting.)
-
The 4:4:0 (h1v2) fancy (smooth) chroma upsampling algorithm in the decompressor now uses a similar bias pattern to that of the 4:2:2 (h2v1) fancy chroma upsampling algorithm, rounding up or down the upsampled result for alternate pixels rather than always rounding down. This ensures that, regardless of whether a 4:2:2 JPEG image is rotated or transposed prior to decompression (in the frequency domain) or after decompression (in the spatial domain), the final image will be similar.
-
Fixed an integer overflow and subsequent segfault that occurred when attempting to compress or decompress images with more than 1 billion pixels using the TurboJPEG API.
-
Fixed a regression introduced by 2.0 beta1[15] whereby attempting to generate a progressive JPEG image on an SSE2-capable CPU using a scan script containing one or more scans with lengths divisible by 16 would result in an error ("Missing Huffman code table entry") and an invalid JPEG image.
-
Fixed an issue whereby
tjDecodeYUV()
andtjDecodeYUVPlanes()
would throw an error ("Invalid progressive parameters") or a warning ("Inconsistent progression sequence") if passed a TurboJPEG instance that was previously used to decompress a progressive JPEG image.
2.0.2
Assets
- libjpeg-turbo-2.0.2.tar.gz is the official source tarball for this release. The automatically generated "Source code" assets are not supported.
- Refer to https://libjpeg-turbo.org/Downloads/DigitalSignatures for information regarding the methods used to sign the files in this release and instructions for verifying the signatures.
- Refer to https://libjpeg-turbo.org/Documentation/OfficialBinaries for information regarding the compatibility of the binary packages in this release.
Support
Code Quality: Stable
Current Support Category: Extended
Release Notes
Significant changes relative to 2.0.1:
-
Fixed a regression introduced by 2.0.1[5] that prevented a runtime search path (rpath) from being embedded in the libjpeg-turbo shared libraries and executables for macOS and iOS. This caused a fatal error of the form "dyld: Library not loaded" when attempting to use one of the executables, unless
DYLD_LIBRARY_PATH
was explicitly set to the location of the libjpeg-turbo shared libraries. -
Fixed an integer overflow and subsequent segfault (CVE-2018-20330) that occurred when attempting to load a BMP file with more than 1 billion pixels using the
tjLoadImage()
function. -
Fixed a buffer overrun (CVE-2018-19664) that occurred when attempting to decompress a specially-crafted malformed JPEG image to a 256-color BMP using djpeg.
-
Fixed a floating point exception that occurred when attempting to decompress a specially-crafted malformed JPEG image with a specified image width or height of 0 using the C version of TJBench.
-
The TurboJPEG API will now decompress 4:4:4 JPEG images with 2x1, 1x2, 3x1, or 1x3 luminance and chrominance sampling factors. This is a non-standard way of specifying 1x subsampling (normally 4:4:4 JPEGs have 1x1 luminance and chrominance sampling factors), but the JPEG format and the libjpeg API both allow it.
-
Fixed a regression introduced by 2.0 beta1[7] that caused djpeg to generate incorrect PPM images when used with the
-colors
option. -
Fixed an issue whereby a static build of libjpeg-turbo (a build in which
ENABLE_SHARED
is0
) could not be installed using the Visual Studio IDE. -
Fixed a severe performance issue in the Loongson MMI SIMD extensions that occurred when compressing RGB images whose image rows were not 64-bit-aligned.
2.0.1
Assets
- libjpeg-turbo-2.0.1.tar.gz is the official source tarball for this release. The automatically generated "Source code" assets are not supported.
- Refer to https://libjpeg-turbo.org/Downloads/DigitalSignatures for information regarding the methods used to sign the files in this release and instructions for verifying the signatures.
- Refer to https://libjpeg-turbo.org/Documentation/OfficialBinaries for information regarding the compatibility of the binary packages in this release.
Support
Code Quality: Stable
Current Support Category: Extended
Release Notes
Significant changes relative to 2.0.0:
-
Fixed a regression introduced with the new CMake-based Un*x build system, whereby jconfig.h could cause compiler warnings of the form
"HAVE_*_H" redefined
if it was included by downstream Autotools-based projects that usedAC_CHECK_HEADERS()
to check for the existence of locale.h, stddef.h, or stdlib.h. -
The
jsimd_quantize_float_dspr2()
andjsimd_convsamp_float_dspr2()
functions in the MIPS DSPr2 SIMD extensions are now disabled at compile time if the soft float ABI is enabled. Those functions use instructions that are incompatible with the soft float ABI. -
Fixed a regression in the SIMD feature detection code, introduced by the AVX2 SIMD extensions (2.0 beta1[1]), that caused libjpeg-turbo to crash on Windows 7 if Service Pack 1 was not installed.
-
Fixed out-of-bounds read in cjpeg that occurred when attempting to compress a specially-crafted malformed color-index (8-bit-per-sample) Targa file in which some of the samples (color indices) exceeded the bounds of the Targa file's color table.
-
Fixed an issue whereby installing a fully static build of libjpeg-turbo (a build in which
CFLAGS
contains-static
andENABLE_SHARED
is0
) would fail with "No valid ELF RPATH or RUNPATH entry exists in the file."
2.0.0
Assets
- libjpeg-turbo-2.0.0.tar.gz is the official source tarball for this release. The automatically generated "Source code" assets are not supported.
- Refer to https://libjpeg-turbo.org/Downloads/DigitalSignatures for information regarding the methods used to sign the files in this release and instructions for verifying the signatures.
- Refer to https://libjpeg-turbo.org/Documentation/OfficialBinaries for information regarding the compatibility of the binary packages in this release.
Support
Code Quality: Stable
Current Support Category: Extended
Release Sponsors
This release was made possible via a generous MOSS (Mozilla Open Source Support) grant from Mozilla Research.
Release Notes
Significant changes relative to 2.0 beta1:
-
The TurboJPEG API can now decompress CMYK JPEG images that have subsampled M and Y components (not to be confused with YCCK JPEG images, in which the C/M/Y components have been transformed into luma and chroma.) Previously, an error was generated ("Could not determine subsampling type for JPEG image") when such an image was passed to
tjDecompressHeader3()
,tjTransform()
,tjDecompressToYUVPlanes()
,tjDecompressToYUV2()
, or the equivalent Java methods. -
Fixed an issue (CVE-2018-11813) whereby a specially-crafted malformed input file (specifically, a file with a valid Targa header but incomplete pixel data) would cause cjpeg to generate a JPEG file that was potentially thousands of times larger than the input file. The Targa reader in cjpeg was not properly detecting that the end of the input file had been reached prematurely, so after all valid pixels had been read from the input, the reader injected dummy pixels with values of 255 into the JPEG compressor until the number of pixels specified in the Targa header had been compressed. The Targa reader in cjpeg now behaves like the PPM reader and aborts compression if the end of the input file is reached prematurely. Because this issue only affected cjpeg and not the underlying library, and because it did not involve any out-of-bounds reads or other exploitable behaviors, it was not believed to represent a security threat.
-
Fixed an issue whereby the
tjLoadImage()
andtjSaveImage()
functions would produce a "Bogus message code" error message if the underlying bitmap and PPM readers/writers threw an error that was specific to the readers/writers (as opposed to a general libjpeg API error.) -
Fixed an issue (CVE-2018-1152) whereby a specially-crafted malformed BMP file, one in which the header specified an image width of 1073741824 pixels, would trigger a floating point exception (division by zero) in the
tjLoadImage()
function when attempting to load the BMP file into a 4-component image buffer. -
Fixed an issue whereby certain combinations of calls to
jpeg_skip_scanlines()
andjpeg_read_scanlines()
could trigger an infinite loop when decompressing progressive JPEG images that use vertical chroma subsampling (for instance, 4:2:0 or 4:4:0.) -
Fixed a segfault in
jpeg_skip_scanlines()
that occurred when decompressing a 4:2:2 or 4:2:0 JPEG image using the merged (non-fancy) upsampling algorithms (that is, when settingcinfo.do_fancy_upsampling
toFALSE
.) -
The new CMake-based build system will now disable the MIPS DSPr2 SIMD extensions if it detects that the compiler does not support DSPr2 instructions.
-
Fixed out-of-bounds read in cjpeg (CVE-2018-14498) that occurred when attempting to compress a specially-crafted malformed color-index (8-bit-per-sample) BMP file in which some of the samples (color indices) exceeded the bounds of the BMP file's color table.
-
Fixed a signed integer overflow in the progressive Huffman decoder, detected by the Clang and GCC undefined behavior sanitizers, that could be triggered by attempting to decompress a specially-crafted malformed JPEG image. This issue did not pose a security threat, but removing the warning made it easier to detect actual security issues, should they arise in the future.
1.5.90 (2.0 beta1)
Assets
- libjpeg-turbo-1.5.90.tar.gz is the official source tarball for this release. The automatically generated "Source code" assets are not supported.
- Refer to https://libjpeg-turbo.org/Downloads/DigitalSignatures for information regarding the methods used to sign the files in this release and instructions for verifying the signatures.
- Refer to https://libjpeg-turbo.org/Documentation/OfficialBinaries for information regarding the compatibility of the binary packages in this release.
Support
Code Quality: Beta
Current Support Category: EOL
Release Notes
Significant changes relative to 1.5.3:
-
Added AVX2 SIMD implementations of the colorspace conversion, chroma downsampling and upsampling, integer quantization and sample conversion, and accurate integer DCT/IDCT algorithms. When using the accurate integer DCT/IDCT algorithms on AVX2-equipped CPUs, the compression of RGB images is approximately 13-36% (avg. 22%) faster (relative to libjpeg-turbo 1.5.x) with 64-bit code and 11-21% (avg. 17%) faster with 32-bit code, and the decompression of RGB images is approximately 9-35% (avg. 17%) faster with 64-bit code and 7-17% (avg. 12%) faster with 32-bit code. (As tested on a 3 GHz Intel Core i7. Actual mileage may vary.)
-
Overhauled the build system to use CMake on all platforms, and removed the autotools-based build system. This decision resulted from extensive discussions within the libjpeg-turbo community. libjpeg-turbo traditionally used CMake only for Windows builds, but there was an increasing amount of demand to extend CMake support to other platforms. However, because of the unique nature of our code base (the need to support different assemblers on each platform, the need for Java support, etc.), providing dual build systems as other OSS imaging libraries do (including libpng and libtiff) would have created a maintenance burden. The use of CMake greatly simplifies some aspects of our build system, owing to CMake's built-in support for various assemblers, Java, and unit testing, as well as generally fewer quirks that have to be worked around in order to implement our packaging system. Eliminating autotools puts our project slightly at odds with the traditional practices of the OSS community, since most "system libraries" tend to be built with autotools, but it is believed that the benefits of this move outweigh the risks. In addition to providing a unified build environment, switching to CMake allows for the use of various build tools and IDEs that aren't supported under autotools, including XCode, Ninja, and Eclipse. It also eliminates the need to install autotools via MacPorts/Homebrew on OS X and allows libjpeg-turbo to be configured without the use of a terminal/command prompt. Extensive testing was conducted to ensure that all features provided by the autotools-based build system are provided by the new build system.
-
The libjpeg API in this version of libjpeg-turbo now includes two additional functions,
jpeg_read_icc_profile()
andjpeg_write_icc_profile()
, that can be used to extract ICC profile data from a JPEG file while decompressing or to embed ICC profile data in a JPEG file while compressing or transforming. This eliminates the need for downstream projects, such as color management libraries and browsers, to include their own glueware for accomplishing this. -
Improved error handling in the TurboJPEG API library:
- Introduced a new function (
tjGetErrorStr2()
) in the TurboJPEG C API that allows compression/decompression/transform error messages to be retrieved in a thread-safe manner. Retrieving error messages from global functions, such astjInitCompress()
ortjBufSize()
, is still thread-unsafe, but since those functions will only throw errors if passed an invalid argument or if a memory allocation failure occurs, thread safety is not as much of a concern. - Introduced a new function (
tjGetErrorCode()
) in the TurboJPEG C API and a new method (TJException.getErrorCode()
) in the TurboJPEG Java API that can be used to determine the severity of the last compression/decompression/transform error. This allows applications to choose whether to ignore warnings (non-fatal errors) from the underlying libjpeg API or to treat them as fatal. - Introduced a new flag (
TJFLAG_STOPONWARNING
in the TurboJPEG C API andTJ.FLAG_STOPONWARNING
in the TurboJPEG Java API) that causes the library to immediately halt a compression/decompression/transform operation if it encounters a warning from the underlying libjpeg API (the default behavior is to allow the operation to complete unless a fatal error is encountered.)
- Introduced a new function (
-
Introduced a new flag in the TurboJPEG C and Java APIs (
TJFLAG_PROGRESSIVE
andTJ.FLAG_PROGRESSIVE
, respectively) that causes compression and transform operations to generate progressive JPEG images. Additionally, a new transform option (TJXOPT_PROGRESSIVE
in the C API andTJTransform.OPT_PROGRESSIVE
in the Java API) has been introduced, allowing progressive JPEG images to be generated by selected transforms in a multi-transform operation. -
Introduced a new transform option in the TurboJPEG API (
TJXOPT_COPYNONE
in the C API andTJTransform.OPT_COPYNONE
in the Java API) that allows the copying of markers (including Exif and ICC profile data) to be disabled for a particular transform. -
Added two functions to the TurboJPEG C API (
tjLoadImage()
andtjSaveImage()
) that can be used to load/save a BMP or PPM/PGM image to/from a memory buffer with a specified pixel format and layout. These functions replace the project-private (and slow) bmp API, which was previously used by TJBench, and they also provide a convenient way for first-time users of libjpeg-turbo to quickly develop a complete JPEG compression/decompression program. -
The TurboJPEG C API now includes a new convenience array (
tjAlphaOffset[]
) that contains the alpha component index for each pixel format (or -1 if the pixel format lacks an alpha component.) The TurboJPEG Java API now includes a new method (TJ.getAlphaOffset()
) that returns the same value. In addition, thetjRedOffset[]
,tjGreenOffset[]
, andtjBlueOffset[]
arrays-- and the correspondingTJ.getRedOffset()
,TJ.getGreenOffset()
, andTJ.getBlueOffset()
methods-- now return -1 forTJPF_GRAY
/TJ.PF_GRAY
rather than 0. This allows programs to easily determine whether a pixel format has red, green, blue, and alpha components. -
Added a new example (tjexample.c) that demonstrates the basic usage of the TurboJPEG C API. This example mirrors the functionality of TJExample.java. Both files are now included in the libjpeg-turbo documentation.
-
Fixed two signed integer overflows in the arithmetic decoder, detected by the Clang undefined behavior sanitizer, that could be triggered by attempting to decompress a specially-crafted malformed JPEG image. These issues did not pose a security threat, but removing the warnings makes it easier to detect actual security issues, should they arise in the future.
-
Fixed a bug in the merged 4:2:0 upsampling/dithered RGB565 color conversion algorithm that caused incorrect dithering in the output image. This algorithm now produces bitwise-identical results to the unmerged algorithms.
-
The SIMD function symbols for x86[-64]/ELF, MIPS/ELF, macOS/x86[-64] (if libjpeg-turbo is built with Yasm), and iOS/Arm[64] builds are now private. This prevents those symbols from being exposed in applications or shared libraries that link statically with libjpeg-turbo.
-
Added Loongson MMI SIMD implementations of the RGB-to-YCbCr and YCbCr-to-RGB colorspace conversion, 4:2:0 chroma downsampling, 4:2:0 fancy chroma upsampling, integer quantization, and accurate integer DCT/IDCT algorithms. When using the accurate integer DCT/IDCT, this speeds up the compression of RGB images by approximately 70-100% and the decompression of RGB images by approximately 2-3.5x.
-
Fixed a build error when building with older MinGW releases (regression caused by 1.5.1[7].)
-
Added SIMD acceleration for progressive Huffman encoding on SSE2-capable x86 and x86-64 platforms. This speeds up the compression of full-color progressive JPEGs by about 85-90% on average (relative to libjpeg-turbo 1.5.x) when using modern Intel and AMD CPUs.
1.5.3
Assets
- libjpeg-turbo-1.5.3.tar.gz is the official source tarball for this release. The automatically generated "Source code" assets are not supported.
- Refer to https://libjpeg-turbo.org/Downloads/DigitalSignatures for information regarding the methods used to sign the files in this release and instructions for verifying the signatures.
- Refer to https://libjpeg-turbo.org/Documentation/OfficialBinaries for information regarding the compatibility of the binary packages in this release.
Support
Code Quality: Stable
Current Support Category: EOL
Release Notes
Significant changes relative to 1.5.2:
-
Fixed a NullPointerException in the TurboJPEG Java wrapper that occurred when using the YUVImage constructor that creates an instance backed by separate image planes and allocates memory for the image planes.
-
Fixed an issue whereby the Java version of TJUnitTest would fail when testing BufferedImage encoding/decoding on big endian systems.
-
Fixed a segfault in djpeg that would occur if an output format other than PPM/PGM was selected along with the
-crop
option. The-crop
option now works with the GIF and Targa formats as well (unfortunately, it cannot be made to work with the BMP and RLE formats due to the fact that those output engines write scanlines in bottom-up order.) djpeg will now exit gracefully if an output format other than PPM/PGM, GIF, or Targa is selected along with the-crop
option. -
Fixed an issue (CVE-2017-15232) whereby
jpeg_skip_scanlines()
would segfault if color quantization was enabled. -
TJBench (both C and Java versions) will now display usage information if any command-line argument is unrecognized. This prevents the program from silently ignoring typos.
-
Fixed an access violation in tjbench.exe (Windows) that occurred when the program was used to decompress an existing JPEG image.
-
Fixed an ArrayIndexOutOfBoundsException in the TJExample Java program that occurred when attempting to decompress a JPEG image that had been compressed with 4:1:1 chrominance subsampling.
-
Fixed an issue whereby, when using
jpeg_skip_scanlines()
to skip to the end of a single-scan (non-progressive) image, subsequent calls tojpeg_consume_input()
would returnJPEG_SUSPENDED
rather thanJPEG_REACHED_EOI
. -
jpeg_crop_scanline()
now works correctly when decompressing grayscale JPEG images that were compressed with a sampling factor other than 1 (for instance, withcjpeg -grayscale -sample 2x2
).
1.5.2
Assets
- libjpeg-turbo-1.5.2.tar.gz is the official source tarball for this release. The automatically generated "Source code" assets are not supported.
- Refer to https://libjpeg-turbo.org/Downloads/DigitalSignatures for information regarding the methods used to sign the files in this release and instructions for verifying the signatures.
- Refer to https://libjpeg-turbo.org/Documentation/OfficialBinaries for information regarding the compatibility of the binary packages in this release.
Support
Code Quality: Stable
Current Support Category: EOL
Release Notes
Significant changes relative to 1.5.1:
-
Fixed a regression introduced by 1.5.1[7] that prevented libjpeg-turbo from building with Android NDK platforms prior to android-21 (5.0).
-
Fixed a regression introduced by 1.5.1[1] that prevented the MIPS DSPR2 SIMD code in libjpeg-turbo from building.
-
Fixed a regression introduced by 1.5 beta1[11] that prevented the Java version of TJBench from outputting any reference images (the
-nowrite
switch was accidentally enabled by default.) -
libjpeg-turbo should now build and run with full AltiVec SIMD acceleration on PowerPC-based AmigaOS 4 and OpenBSD systems.
-
Fixed build and runtime errors on Windows that occurred when building libjpeg-turbo with libjpeg v7 API/ABI emulation and the in-memory source/destination managers. Due to an oversight, the
jpeg_skip_scanlines()
andjpeg_crop_scanline()
functions were not being included in jpeg7.dll when libjpeg-turbo was built with-DWITH_JPEG7=1
and-DWITH_MEMSRCDST=1
. -
Fixed "Bogus virtual array access" error that occurred when using the lossless crop feature in jpegtran or the TurboJPEG API, if libjpeg-turbo was built with libjpeg v7 API/ABI emulation. This was apparently a long-standing bug that has existed since the introduction of libjpeg v7/v8 API/ABI emulation in libjpeg-turbo v1.1.
-
The lossless transform features in jpegtran and the TurboJPEG API will now always attempt to adjust the Exif image width and height tags if the image size changed as a result of the transform. This behavior has always existed when using libjpeg v8 API/ABI emulation. It was supposed to be available with libjpeg v7 API/ABI emulation as well but did not work properly due to a bug. Furthermore, there was never any good reason not to enable it with libjpeg v6b API/ABI emulation, since the behavior is entirely internal. Note that
-copy all
must be passed to jpegtran in order to transfer the Exif tags from the source image to the destination image. -
Fixed several memory leaks in the TurboJPEG API library that could occur if the library was built with certain compilers and optimization levels (known to occur with GCC 4.x and clang with
-O1
and higher but not with GCC 5.x or 6.x) and one of the underlying libjpeg API functions threw an error after a TurboJPEG API function allocated a local buffer. -
The libjpeg-turbo memory manager will now honor the
max_memory_to_use
structure member in jpeg_memory_mgr, which can be set to the maximum amount of memory (in bytes) that libjpeg-turbo should use during decompression or multi-pass (including progressive) compression. This limit can also be set using theJPEGMEM
environment variable or using the-maxmemory
switch in cjpeg/djpeg/jpegtran (refer to the respective man pages for more details.) This has been a documented feature of libjpeg since v5, but themalloc()
/free()
implementation of the memory manager (jmemnobs.c) never implemented the feature. Restricting libjpeg-turbo's memory usage is useful for two reasons: it allows testers to more easily work around the 2 GB limit in libFuzzer, and it allows developers of security-sensitive applications to more easily defend against one of the progressive JPEG exploits (LJT-01-004) identified in this report. -
TJBench will now run each benchmark for 1 second prior to starting the timer, in order to improve the consistency of the results. Furthermore, the
-warmup
option is now used to specify the amount of warmup time rather than the number of warmup iterations. -
Fixed an error (
short jump is out of range
) that occurred when assembling the 32-bit x86 SIMD extensions with NASM versions prior to 2.04. This was a regression introduced by 1.5 beta1[12].
1.5.1
Assets
- libjpeg-turbo-1.5.1.tar.gz is the official source tarball for this release. The automatically generated "Source code" assets are not supported.
- Refer to https://libjpeg-turbo.org/Downloads/DigitalSignatures for information regarding the methods used to sign the files in this release and instructions for verifying the signatures.
- Refer to https://libjpeg-turbo.org/Documentation/OfficialBinaries for information regarding the compatibility of the binary packages in this release.
- The iOS binaries are now built using Clang in Xcode 7.2.x with bitcode enabled. Testing has revealed no significant performance regression from this, and it greatly facilitates using libjpeg-turbo to develop applications for iOS 9 and later, as well as watchOS and tvOS (both of which require bitcode.)
Packaging Changes
- The iOS binaries are now built using Clang in Xcode 7.2.x with bitcode enabled. Testing has revealed no significant performance regression from this, and it greatly facilitates using libjpeg-turbo to develop applications for iOS 9 and later, as well as watchOS and tvOS (both of which require bitcode.)
Support
Code Quality: Stable
Current Support Category: EOL
Release Notes
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 theJSIMD_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 existingJSIMD_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
andJSIMD_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 variableJSIMD_FORCENONE
to1
. -
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 format 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.90[2] (partial image decompression) 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.
1.5.0
Assets
- libjpeg-turbo-1.5.0.tar.gz is the official source tarball for this release. The automatically generated "Source code" assets are not supported.
- Refer to https://libjpeg-turbo.org/Downloads/DigitalSignatures for information regarding the methods used to sign the files in this release and instructions for verifying the signatures.
- Refer to https://libjpeg-turbo.org/Documentation/OfficialBinaries for information regarding the compatibility of the binary packages in this release.
Support
Code Quality: Stable
Current Support Category: EOL
Release Notes
Significant changes relative to 1.5 beta1:
-
Fixed an issue whereby a malformed motion-JPEG frame could cause the "fast path" of libjpeg-turbo's Huffman decoder to read from uninitialized memory.
-
Added libjpeg-turbo version and build information to the global string table of the libjpeg and TurboJPEG API libraries. This is a common practice in other infrastructure libraries, such as OpenSSL and libpng, because it makes it easy to examine an application binary and determine which version of the library the application was linked against.
-
Fixed a couple of issues in the PPM reader that would cause buffer overruns in cjpeg if one of the values in a binary PPM/PGM input file exceeded the maximum value defined in the file's header and that maximum value was greater than 255. libjpeg-turbo 1.4.2 already included a similar fix for ASCII PPM/PGM files. Note that these issues were not security bugs, since they were confined to the cjpeg program and did not affect any of the libjpeg-turbo libraries.
-
Fixed an issue whereby attempting to decompress a JPEG file with a corrupt header using the
tjDecompressToYUV2()
function would cause the function to abort without returning an error and, under certain circumstances, corrupt the stack. This only occurred iftjDecompressToYUV2()
was called prior to callingtjDecompressHeader3()
, or if the return value fromtjDecompressHeader3()
was ignored (both cases represent incorrect usage of the TurboJPEG API.) -
Fixed an issue in the ARM 32-bit SIMD-accelerated Huffman encoder that prevented the code from assembling properly with clang.
-
The
jpeg_stdio_src()
,jpeg_mem_src()
,jpeg_stdio_dest()
, andjpeg_mem_dest()
functions in the libjpeg API will now throw an error if a source/destination manager has already been assigned to the compress or decompress object by a different function or by the calling program. This prevents these functions from attempting to reuse a source/destination manager structure that was allocated elsewhere, because there is no way to ensure that it would be big enough to accommodate the new source/destination manager.