Page MenuHomeSolus

Update libjpeg-turbo to 2.0.4
ClosedPublic

Authored by fmonteiro on Jan 1 2020, 10:27 PM.
Tags
None
Referenced Files
F11048847: D7946.id19027.diff
Thu, Aug 10, 5:03 PM
F11048846: D7946.id19272.diff
Thu, Aug 10, 5:03 PM
F11048845: D7946.id.diff
Thu, Aug 10, 5:03 PM
F11034408: D7946.diff
Wed, Aug 9, 4:47 PM
F10993314: D7946.diff
Tue, Jul 25, 4:39 PM
F10879640: D7946.id.diff
Jun 22 2023, 4:16 AM
F10878805: D7946.id19272.diff
Jun 21 2023, 2:20 PM
F10876452: D7946.id19027.diff
Jun 20 2023, 11:06 AM
Subscribers

Details

Summary

Changelog:

  • 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() 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).
  • 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().
  • 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.
  • 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.
Test Plan

Builds fine all tests pass.

Diff Detail

Repository
R1749 libjpeg-turbo
Branch
master
Lint
No Lint Coverage
Unit
No Test Coverage

Event Timeline

fmonteiro created this revision.
This revision is now accepted and ready to land.Jan 14 2020, 1:38 AM
This revision was automatically updated to reflect the committed changes.