Opened 4 years ago

Closed 4 years ago

#12966 closed enhancement (fixed)

libjpeg-turbo-2.0.4

Reported by: Bruce Dubbs Owned by: Bruce Dubbs
Priority: normal Milestone: 9.1
Component: BOOK Version: SVN
Severity: normal Keywords:
Cc:

Description

New point version.

Change History (3)

comment:1 by Bruce Dubbs, 4 years ago

# 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.
  1. Fixed a signed integer overflow and subsequent segfault that occurred when attempting to decompress images with more than 715,827,882 pixels using the 64-bit C version of TJBench.
  1. 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).
  1. 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().
  1. 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.
  1. 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.

comment:2 by Bruce Dubbs, 4 years ago

Owner: changed from blfs-book to Bruce Dubbs
Status: newassigned

comment:3 by Bruce Dubbs, 4 years ago

Resolution: fixed
Status: assignedclosed

Fixed at revision 22533.

Note: See TracTickets for help on using tickets.