libjpeg-turbo/libjpeg-turbo 2.0.4

on GitHub

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

Significant changes relative to 2.0.3:

1. 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.

2. 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.

3. 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).

4. 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().

5. 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.

6. 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.