2022-02-27 09:50:48 by Adam Ciarcinski | Files touched by this commit (2) | |
Log message:
libjpeg-turbo: updated to 2.1.3
Significant changes relative to 2.1.2
Fixed a regression introduced by 2.0 beta1[7] whereby cjpeg compressed PGM input \
files into full-color JPEG images unless the -grayscale option was used.
cjpeg now automatically compresses GIF and 8-bit BMP input files into grayscale \
JPEG images if the input files contain only shades of gray.
The build system now enables the intrinsics implementation of the AArch64 (Arm \
64-bit) Neon SIMD extensions by default when using GCC 12 or later.
Fixed a segfault that occurred while decompressing a 4:2:0 JPEG image using the \
merged (non-fancy) upsampling algorithms (that is, with \
cinfo.do_fancy_upsampling set to FALSE) along with jpeg_crop_scanline(). \
Specifically, the segfault occurred if the number of bytes remaining in the \
output buffer was less than the number of bytes required to represent one \
uncropped scanline of the output image. For that reason, the issue could only be \
reproduced using the libjpeg API, not using djpeg.
|
2021-11-19 22:55:01 by Adam Ciarcinski | Files touched by this commit (2) | |
Log message:
libjpeg-turbo: updated to 2.1.2
2.1.2
=====
Significant changes relative to 2.1.1
1. Fixed a regression introduced by 2.1 beta1[13] that caused the remaining
GAS implementations of AArch64 (Arm 64-bit) Neon SIMD functions (which are used
by default with GCC for performance reasons) to be placed in the `.rodata`
section rather than in the `.text` section. This caused the GNU linker to
automatically place the `.rodata` section in an executable segment, which
prevented libjpeg-turbo from working properly with other linkers and also
represented a potential security risk.
2. Fixed an issue whereby the `tjTransform()` function incorrectly computed the
MCU block size for 4:4:4 JPEG images with non-unary sampling factors and thus
unduly rejected some cropping regions, even though those regions aligned with
8x8 MCU block boundaries.
3. Fixed a regression introduced by 2.1 beta1[13] that caused the build system
to enable the Arm Neon SIMD extensions when targetting Armv6 and other legacy
architectures that do not support Neon instructions.
4. libjpeg-turbo now performs run-time detection of AltiVec instructions on
FreeBSD/PowerPC systems if AltiVec instructions are not enabled at compile
time. This allows both AltiVec-equipped and non-AltiVec-equipped CPUs to be
supported using the same build of libjpeg-turbo.
5. cjpeg now accepts a `-strict` argument similar to that of djpeg and
jpegtran, which causes the compressor to abort if an LZW-compressed GIF input
image contains incomplete or corrupt image data.
|
2021-10-26 12:47:26 by Nia Alarie | Files touched by this commit (800) |
Log message:
graphics: Replace RMD160 checksums with BLAKE2s checksums
All checksums have been double-checked against existing RMD160 and
SHA512 hashes
|
2021-10-07 16:13:27 by Nia Alarie | Files touched by this commit (800) |
Log message:
graphics: Remove SHA1 hashes for distfiles
|
2021-08-10 11:13:54 by Adam Ciarcinski | Files touched by this commit (2) | |
Log message:
libjpeg-turbo: updated to 2.1.1
2.1.1
Significant changes relative to 2.1.0
Fixed a regression introduced in 2.1.0 that caused build failures with \
non-GCC-compatible compilers for Un*x/Arm platforms.
Fixed a regression introduced by 2.1 beta1[13] that prevented the Arm 32-bit \
(AArch32) Neon SIMD extensions from building unless the C compiler flags \
included -mfloat-abi=softfp or -mfloat-abi=hard.
Fixed an issue in the AArch32 Neon SIMD Huffman encoder whereby reliance on \
undefined C compiler behavior led to crashes ("SIGBUS: illegal \
alignment") on Android systems when running AArch32/Thumb builds of \
libjpeg-turbo built with recent versions of Clang.
Added a command-line argument (-copy icc) to jpegtran that causes it to copy \
only the ICC profile markers from the source file and discard any other \
metadata.
libjpeg-turbo should now build and run on CHERI-enabled architectures, which use \
capability pointers that are larger than the size of size_t.
Fixed a regression introduced by 2.1 beta1[5] that caused a segfault in the \
64-bit SSE2 Huffman encoder when attempting to losslessly transform a \
specially-crafted malformed JPEG image.
|
2021-04-26 10:18:48 by Adam Ciarcinski | Files touched by this commit (6) | |
Log message:
libjpeg-turbo: updated to 2.1.0
2.1.0
Significant changes relative to 2.1 beta1
Fixed a regression introduced by 2.1 beta1[6(b)] whereby attempting to \
decompress certain progressive JPEG images with one or more component planes of \
width 8 or less caused a buffer overrun.
Fixed a regression introduced by 2.1 beta1[6(b)] whereby attempting to \
decompress a specially-crafted malformed progressive JPEG image caused the block \
smoothing algorithm to read from uninitialized memory.
Fixed an issue in the Arm Neon SIMD Huffman encoders that caused the encoders to \
generate incorrect results when using the Clang compiler with Visual Studio.
Fixed a floating point exception (CVE-2021-20205) that occurred when attempting \
to compress a specially-crafted malformed GIF image with a specified image width \
of 0 using cjpeg.
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 32 and non-zero successive approximation \
low bit positions would, under certain circumstances, result in an error \
("Missing Huffman code table entry") and an invalid JPEG image.
Introduced a new flag (TJFLAG_LIMITSCANS in the TurboJPEG C API and \
TJ.FLAG_LIMIT_SCANS in the TurboJPEG Java API) and a corresponding TJBench \
command-line argument (-limitscans) that causes the TurboJPEG decompression and \
transform functions/operations to return/throw an error if a progressive JPEG \
image contains an unreasonably large number of scans. This allows applications \
that use the TurboJPEG API to guard against an exploit of the progressive JPEG \
format described in the report "Two Issues with the JPEG Standard".
The PPM reader now throws an error, rather than segfaulting (due to a buffer \
overrun) or generating incorrect pixels, if an application attempts to use the \
tjLoadImage() function to load a 16-bit binary PPM file (a binary PPM file with \
a maximum value greater than 255) into a grayscale image buffer or to load a \
16-bit binary PGM file into an RGB image buffer.
Fixed an issue in the PPM reader that caused incorrect pixels to be generated \
when using the tjLoadImage() function to load a 16-bit binary PPM file into an \
extended RGB image buffer.
Fixed an issue whereby, if a JPEG buffer was automatically re-allocated by one \
of the TurboJPEG compression or transform functions and an error subsequently \
occurred during compression or transformation, the JPEG buffer pointer passed by \
the application was not updated when the function returned.
2.0.90 (2.1 beta1)
Significant changes relative to 2.0.6:
The build system, x86-64 SIMD extensions, and accelerated Huffman codec now \
support the x32 ABI on Linux, which allows for using x86-64 instructions with \
32-bit pointers. The x32 ABI is generally enabled by adding -mx32 to the \
compiler flags.
Caveats:
CMake 3.9.0 or later is required in order for the build system to automatically \
detect an x32 build.
Java does not support the x32 ABI, and thus the TurboJPEG Java API will \
automatically be disabled with x32 builds.
Added Loongson MMI SIMD implementations of the RGB-to-grayscale, 4:2:2 fancy \
chroma upsampling, 4:2:2 and 4:2:0 merged chroma upsampling/color conversion, \
and fast integer DCT/IDCT algorithms. Relative to libjpeg-turbo 2.0.x, this \
speeds up:
the compression of RGB source images into grayscale JPEG images by approximately 20%
the decompression of 4:2:2 JPEG images by approximately 40-60% when using fancy \
upsampling
the decompression of 4:2:2 and 4:2:0 JPEG images by approximately 15-20% when \
using merged upsampling
the compression of RGB source images by approximately 30-45% when using the fast \
integer DCT
the decompression of JPEG images into RGB destination images by approximately 2x \
when using the fast integer IDCT
The overall decompression speedup for RGB images is now approximately 2.3-3.7x \
(compared to 2-3.5x with libjpeg-turbo 2.0.x.)
32-bit (Armv7 or Armv7s) iOS builds of libjpeg-turbo are no longer supported, \
and the libjpeg-turbo build system can no longer be used to package such builds. \
32-bit iOS apps cannot run in iOS 11 and later, and the App Store no longer \
allows them.
32-bit (i386) OS X/macOS builds of libjpeg-turbo are no longer supported, and \
the libjpeg-turbo build system can no longer be used to package such builds. \
32-bit Mac applications cannot run in macOS 10.15 "Catalina" and \
later, and the App Store no longer allows them.
The SSE2 (x86 SIMD) and C Huffman encoding algorithms have been significantly \
optimized, resulting in a measured average overall compression speedup of 12-28% \
for 64-bit code and 22-52% for 32-bit code on various Intel and AMD CPUs, as \
well as a measured average overall compression speedup of 0-23% on platforms \
that do not have a SIMD-accelerated Huffman encoding implementation.
The block smoothing algorithm that is applied by default when decompressing \
progressive Huffman-encoded JPEG images has been improved in the following ways:
The algorithm is now more fault-tolerant. Previously, if a particular scan was \
incomplete, then the smoothing parameters for the incomplete scan would be \
applied to the entire output image, including the parts of the image that were \
generated by the prior (complete) scan. Visually, this had the effect of \
removing block smoothing from lower-frequency scans if they were followed by an \
incomplete higher-frequency scan. libjpeg-turbo now applies block smoothing \
parameters to each iMCU row based on which scan generated the pixels in that \
row, rather than always using the block smoothing parameters for the most recent \
scan.
When applying block smoothing to DC scans, a Gaussian-like kernel with a 5x5 \
window is used to reduce the "blocky" appearance.
Added SIMD acceleration for progressive Huffman encoding on Arm platforms. This \
speeds up the compression of full-color progressive JPEGs by about 30-40% on \
average (relative to libjpeg-turbo 2.0.x) when using modern Arm CPUs.
Added configure-time and run-time auto-detection of Loongson MMI SIMD \
instructions, so that the Loongson MMI SIMD extensions can be included in any \
MIPS64 libjpeg-turbo build.
Added fault tolerance features to djpeg and jpegtran, mainly to demonstrate \
methods by which applications can guard against the exploits of the JPEG format \
described in the report "Two Issues with the JPEG Standard".
Both programs now accept a -maxscans argument, which can be used to limit the \
number of allowable scans in the input file.
Both programs now accept a -strict argument, which can be used to treat all \
warnings as fatal.
CMake package config files are now included for both the libjpeg and TurboJPEG \
API libraries. This facilitates using libjpeg-turbo with CMake's find_package() \
function. For example:
find_package(libjpeg-turbo CONFIG REQUIRED)
add_executable(libjpeg_program libjpeg_program.c)
target_link_libraries(libjpeg_program PUBLIC libjpeg-turbo::jpeg)
add_executable(libjpeg_program_static libjpeg_program.c)
target_link_libraries(libjpeg_program_static PUBLIC
libjpeg-turbo::jpeg-static)
add_executable(turbojpeg_program turbojpeg_program.c)
target_link_libraries(turbojpeg_program PUBLIC
libjpeg-turbo::turbojpeg)
add_executable(turbojpeg_program_static turbojpeg_program.c)
target_link_libraries(turbojpeg_program_static PUBLIC
libjpeg-turbo::turbojpeg-static)
Since the Unisys LZW patent has long expired, cjpeg and djpeg can now read/write \
both LZW-compressed and uncompressed GIF files (feature ported from jpeg-6a and \
jpeg-9d.)
jpegtran now includes the -wipe and -drop options from jpeg-9a and jpeg-9d, as \
well as the ability to expand the image size using the -crop option. Refer to \
jpegtran.1 or usage.txt for more details.
Added a complete intrinsics implementation of the Arm Neon SIMD extensions, thus \
providing SIMD acceleration on Arm platforms for all of the algorithms that are \
SIMD-accelerated on x86 platforms. This new implementation is significantly \
faster in some cases than the old GAS implementation-- depending on the \
algorithms used, the type of CPU core, and the compiler. GCC, as of this \
writing, does not provide a full or optimal set of Neon intrinsics, so for \
performance reasons, the default when building libjpeg-turbo with GCC is to \
continue using the GAS implementation of the following algorithms:
32-bit RGB-to-YCbCr color conversion
32-bit fast and accurate inverse DCT
64-bit RGB-to-YCbCr and YCbCr-to-RGB color conversion
64-bit accurate forward and inverse DCT
64-bit Huffman encoding
A new CMake variable (NEON_INTRINSICS) can be used to override this default.
Since the new intrinsics implementation includes SIMD acceleration for merged \
upsampling/color conversion, 1.5.1[5] is no longer necessary and has been \
reverted.
The Arm Neon SIMD extensions can now be built using Visual Studio.
The build system can now be used to generate a universal x86-64 + Armv8 \
libjpeg-turbo SDK package for both iOS and macOS.
|
2021-04-01 00:26:51 by Greg Troxel | Files touched by this commit (2) |
Log message:
libjpeg-turbo: Change symbol in undocumented patch to one that isn't undefined
With this change, libjpeg-turbo builds on earmv7hf-el. That seems
like an improvement over not building, and no better ideas were
received.
|
2020-11-17 09:46:47 by Adam Ciarcinski | Files touched by this commit (2) | |
Log message:
libjpeg-turbo: updated to 2.0.6
2.0.6
Significant changes relative to 2.0.5:
Fixed "using JNI after critical get" errors that occurred on Android \
platforms when using any of the YUV encoding/compression/decompression/decoding \
methods in the TurboJPEG Java API.
Fixed or worked around multiple issues with jpeg_skip_scanlines():
Fixed segfaults or "Corrupt JPEG data: premature end of data segment" \
errors in jpeg_skip_scanlines() that occurred when decompressing 4:2:2 or 4:2:0 \
JPEG images using merged (non-fancy) upsampling/color conversion (that is, when \
setting cinfo.do_fancy_upsampling to FALSE.) 2.0.0[6] was a similar fix, but it \
did not cover all cases.
jpeg_skip_scanlines() now throws an error if two-pass color quantization is \
enabled. Two-pass color quantization never worked properly with \
jpeg_skip_scanlines(), and the issues could not readily be fixed.
Fixed an issue whereby jpeg_skip_scanlines() always returned 0 when skipping \
past the end of an image.
The Arm 64-bit (Armv8) Neon SIMD extensions can now be built using MinGW \
toolchains targetting Arm64 (AArch64) Windows binaries.
Fixed unexpected visual artifacts that occurred when using jpeg_crop_scanline() \
and interblock smoothing while decompressing only the DC scan of a progressive \
JPEG image.
Fixed an issue whereby libjpeg-turbo would not build if 12-bit-per-component \
JPEG support (WITH_12BIT) was enabled along with libjpeg v7 or libjpeg v8 \
API/ABI emulation (WITH_JPEG7 or WITH_JPEG8.)
|
2020-06-30 08:03:04 by Adam Ciarcinski | Files touched by this commit (2) | |
Log message:
libjpeg-turbo: updated to 2.0.5
2.0.5
Significant changes relative to 2.0.4:
Worked around issues in the MIPS DSPr2 SIMD extensions that caused failures in \
the libjpeg-turbo regression tests. Specifically, the \
jsimd_h2v1_downsample_dspr2() and jsimd_h2v2_downsample_dspr2() functions in the \
MIPS DSPr2 SIMD extensions are now disabled until/unless they can be fixed, and \
other functions that are incompatible with big endian MIPS CPUs are disabled \
when building libjpeg-turbo for such CPUs.
Fixed an oversight in the TJCompressor.compress(int) method in the TurboJPEG \
Java API that caused an error ("java.lang.IllegalStateException: No source \
image is associated with this instance") when attempting to use that method \
to compress a YUV image.
Fixed an issue (CVE-2020-13790) in the PPM reader that caused a buffer overrun \
in cjpeg, TJBench, or the tjLoadImage() function 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 less than 255. libjpeg-turbo 1.5.0 already \
included a similar fix for binary PPM/PGM files with maximum values greater than \
255.
The TurboJPEG API library's global error handler, which is used in functions \
such as tjBufSize() and tjLoadImage() that do not require a TurboJPEG instance \
handle, is now thread-safe on platforms that support thread-local storage.
|
2020-04-12 08:17:06 by Adam Ciarcinski | Files touched by this commit (7) | |
Log message:
libjpeg-turbo: updated to 2.0.4
2.0.4
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.
2.0.3
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() and tjDecodeYUVPlanes() 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
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 is 0) 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
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 used \
AC_CHECK_HEADERS() to check for the existence of locale.h, stddef.h, or \
stdlib.h.
The jsimd_quantize_float_dspr2() and jsimd_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 and ENABLE_SHARED is 0) would fail with \
"No valid ELF RPATH or RUNPATH entry exists in the file."
2.0.0
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() and tjSaveImage() 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() \
and jpeg_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 setting cinfo.do_fancy_upsampling to FALSE.)
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.
|