libjpeg: Update to version 3.2.1

- Update from version 3.2.0 to 3.2.1
- No change in rootfile
- 1 CVE fix
- Changelog
3.2.1
	1. Fixed a regression introduced by 3.2 beta1[9] that broke Un*x builds in
	 which position-independent code (PIC) was not enabled for static libraries.
	 This issue could be worked around by explicitly setting the
	 `CMAKE_POSITION_INDEPENDENT_CODE` CMake variable or using a toolchain, such as
	 the ones provided by Ubuntu, that automatically enables PIC.
	2. The RISC-V Vector (RVV) forward DCT modules now use strided segment load
	 intrinsics to simultaneously load sample rows from memory and transpose them
	 into columns, as well as multiply-accumulate intrinsics where appropriate.
	 When using the accurate integer DCT algorithm, RGB-to-baseline JPEG compression
	 is approximately 10-17% (avg. 13%) faster (relative to libjpeg-turbo 3.2.0)
	 with GCC 14 and 1-8% (avg. 4%) faster with Clang 20.  (Tested on a 1.6 GHz Ky
	 X1 CPU.  Actual mileage may vary.)
	3. Symbols from the in-tree zlib and libspng implementations introduced by
	 3.2 beta1[9] are now hidden, which prevents the symbols from being exposed in
	 downstream shared libraries and applications that link with the static
	 TurboJPEG API library.  Symbols from the in-tree zlib implementation are now
	 also renamed, which prevents downstream shared libraries and applications that
	 link with the static TurboJPEG API library from accidentally calling the
	 in-tree zlib implementation when they intend to call the system-supplied zlib
	 implementation.
	4. Fixed an integer overflow and subsequent buffer overrun that occurred when
	 attempting to use `tj3LoadImage12()` or `tj3LoadImage16()` from a 32-bit build
	 of libjpeg-turbo to load a packed-pixel image with more than 2^31 components.
	5. Fixed a division-by-zero error (CVE-2026-75466) that occurred when
	 attempting to load a non-grayscale indexed-color PNG image using
	 `tj3LoadImage*()` if the pixel format of the packed-pixel buffer was
	 unspecified (`TJPF_UNKNOWN`.)
	6. Fixed an issue whereby `tj3DecompressToYUV*()` produced incorrect
	 chrominance values when decompressing a 4:2:0, 4:1:0, or 2:4 JPEG image with
	 the "fast" IDCT algorithm and a scaling factor of 1/2.  (In other words,
	 `TJPARAM_FASTDCT` was not ignored as it should be when decompression scaling is
	 enabled.)
	7. Fixed a buffer overrun and subsequent segfault that occurred on certain
	 platforms when attempting to partially decompress a specially-crafted 4:2:0
	 JPEG image using the merged (non-fancy) upsampling algorithm with the
	 libjpeg-turbo SIMD extensions disabled and a cropping region that would have
	 caused any of the component planes to be cropped to a width of 1 or 2 samples.
	8. Hardened the libjpeg API against hypothetical applications that may
	 erroneously attempt to decompress a full-color 12-bit-per-sample JPEG image
	 with both one-pass color quantization and RGB565 color conversion enabled.
	 This could have caused a buffer overrun in one of the quantizer's color index
	 arrays.  The buffer overrun did not likely pose a security risk, since an
	 application that abused the API in the aforementioned manner could never work
	 properly.
	9. Fixed issues in `jpeg*_skip_scanlines()` whereby, when skipping certain
	 groups of scanlines while using a non-fancy (merged or plain) upsampling
	 algorithm with a vertical sampling factor greater than 1, the wrong number of
	 scanlines were skipped and/or skipped scanlines were returned in subsequent
	 calls to `jpeg*_read_scanlines()`.
	10. Hardened the TurboJPEG API against hypothetical applications that may
	 erroneously pass an invalid image to `tj3DecompressHeader()`, ignore a fatal
	 error thrown by that function, and attempt to call the function again with a
	 valid image.  Under certain circumstances, this could have caused the values of
	 `TJPARAM_JPEGWIDTH` and `TJPARAM_JPEGHEIGHT` to reflect the dimensions reported
	 in the invalid image's header rather than the valid image's header, which might
	 have caused the caller to allocate too small of a buffer to hold the
	 decompressed valid image.
	11. `tj3DecompressHeader()` now always removes the ICC profile (if any) that
	 was previously extracted into the TurboJPEG instance.  This addresses an
	 oversight in 3.2 beta1[10] whereby, if the same TurboJPEG instance was used to
	 decompress or transform multiple JPEG images, then `tj3GetICCProfile()` and
	 `tj3TransformBufSize()` behaved as if JPEG images with no ICC profile contained
	 the last ICC profile extracted.
	12. `tj3TransformBufSize()` has been improved in the following ways:
	     - The function now accounts for the size of all extra markers (including
	 comments, JFIF thumbnails, and Exif data) that will be copied from the source
	 image to the destination image, given the current value of
	 `TJPARAM_SAVEMARKERS` and the specified transform options.
	     - The function now returns accurate results regardless of the value of
	 `TJPARAM_SAVEMARKERS` at the time `tj3DecompressHeader()` was called.  This
	 reflects the fact that only the current value of `TJPARAM_SAVEMARKERS` and the
	 specified transform options affect the marker copying behavior in
	 `tj3Transform()`.
	13. Fixed issues in jpegtran that prevented a grayscale image from being
	 dropped into a subsampled input image or vice versa.
	14. Hardened the TurboJPEG API against hypothetical applications that may
	 erroneously attempt to use the same insufficiently large pre-allocated
	 destination buffer for multiple simultaneous transform operations in
	 `tj3Transform()`.  This caused a use-after-free issue, because the
	 caller-specified destination buffer was no longer valid after the first
	 transform operation reallocated it.
	15. Fixed multiple issues in the standalone (non-merged) RGB565 color
	 converters that occurred when attempting to decompress more than one scanline
	 at a time from a vertically subsampled JPEG image.  These issues caused a
	 buffer overrun and subsequent segfault if the output image rows were not 4-byte
	 aligned, the image width was 1, and both the vertical sampling factor and the
	 number of scanlines decompressed at a time were greater than 2.  In other
	 cases, the issues caused incorrect dithered output.  The issues could not be
	 reproduced using djpeg (which decompresses one scanline at a time) and were not
	 known to exist in any other applications.

Signed-off-by: Adolf Belka <adolf.belka@ipfire.org>
---
 lfs/libjpeg | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)