CVS commit: pkgsrc/graphics/libjpeg-turbo

["Adam Ciarcinski" <adam%netbsd.org@localhost>]

Module Name:    pkgsrc
Committed By:   adam
Date:           Wed Oct 28 05:19:37 UTC 2026

Modified Files:
        pkgsrc/graphics/libjpeg-turbo: Makefile distinfo
Removed Files:
        pkgsrc/graphics/libjpeg-turbo/patches: patch-release_Config.cmake.in

Log Message:
libjpeg-turbo: updated to 3.2.1

Significant changes relative to 3.2.0:

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.

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

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.

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.

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

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

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.

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.

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

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.

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.

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().
Fixed issues in jpegtran that prevented a grayscale image from being dropped into a subsampled input image or vice versa.

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.

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.


To generate a diff of this commit:
cvs rdiff -u -r1.48 -r1.49 pkgsrc/graphics/libjpeg-turbo/Makefile
cvs rdiff -u -r1.40 -r1.41 pkgsrc/graphics/libjpeg-turbo/distinfo
cvs rdiff -u -r1.1 -r0 \
    pkgsrc/graphics/libjpeg-turbo/patches/patch-release_Config.cmake.in

Please note that diffs are not public domain; they are subject to the
copyright notices on the relevant files.

Modified files:

Index: pkgsrc/graphics/libjpeg-turbo/Makefile
diff -u pkgsrc/graphics/libjpeg-turbo/Makefile:1.48 pkgsrc/graphics/libjpeg-turbo/Makefile:1.49
--- pkgsrc/graphics/libjpeg-turbo/Makefile:1.48 Mon Aug 17 15:27:47 2026
+++ pkgsrc/graphics/libjpeg-turbo/Makefile      Wed Oct 28 05:19:37 2026
@@ -1,7 +1,6 @@
-# $NetBSD: Makefile,v 1.48 2026/08/17 15:27:47 ryoon Exp $
+# $NetBSD: Makefile,v 1.49 2026/10/28 05:19:37 adam Exp $
 
-DISTNAME=      libjpeg-turbo-3.2.0
-PKGREVISION=   2
+DISTNAME=      libjpeg-turbo-3.2.1
 CATEGORIES=    graphics
 MASTER_SITES=  ${MASTER_SITE_GITHUB:=libjpeg-turbo/}
 
@@ -16,7 +15,7 @@ LICENSE=      gnu-lgpl-v2 AND ijg # OR wxWind
 CONFLICTS=     jpeg-[0-9]*
 
 .if ${MACHINE_ARCH} == x86_64 || ${MACHINE_ARCH} == i386
-TOOL_DEPENDS+= nasm-[0-9]*:../../devel/nasm
+TOOL_DEPENDS+= nasm>=0:../../devel/nasm
 .endif
 
 USE_LANGUAGES=         c c++

Index: pkgsrc/graphics/libjpeg-turbo/distinfo
diff -u pkgsrc/graphics/libjpeg-turbo/distinfo:1.40 pkgsrc/graphics/libjpeg-turbo/distinfo:1.41
--- pkgsrc/graphics/libjpeg-turbo/distinfo:1.40 Wed Jul  8 09:50:24 2026
+++ pkgsrc/graphics/libjpeg-turbo/distinfo      Wed Oct 28 05:19:37 2026
@@ -1,10 +1,9 @@
-$NetBSD: distinfo,v 1.40 2026/07/08 09:50:24 adam Exp $
+$NetBSD: distinfo,v 1.41 2026/10/28 05:19:37 adam Exp $
 
-BLAKE2s (libjpeg-turbo-3.2.0.tar.gz) = c159504a910ac29d4c7775bb3e5c6a59db79e38b77d956df349987a5df0234cb
-SHA512 (libjpeg-turbo-3.2.0.tar.gz) = 1ce063e9e126d55019385da3a6ff4521a9a3958edeab15e2465ae3435026dac6e598277eea066173ada47da37159d0f7812b2227869c10dd141dcfe2ddeab720
-Size (libjpeg-turbo-3.2.0.tar.gz) = 2537858 bytes
+BLAKE2s (libjpeg-turbo-3.2.1.tar.gz) = 4d3f9f37056bc8fabdceeda888300cff81d619cea315f28426cb0a1dc7464e29
+SHA512 (libjpeg-turbo-3.2.1.tar.gz) = 680b97652a51846e1965e70b5498f74ebf9e6eaa31c122546ba7b8eff9fa6b6eb85972802970e94cce4f539518ad421395eaffe121bce7ad7b8f23a9ab9731ef
+Size (libjpeg-turbo-3.2.1.tar.gz) = 2549854 bytes
 SHA1 (patch-CMakeLists.txt) = ed81aa8def09bd03ff0c0a31ef2d7cac0bf06c8f
 SHA1 (patch-cmakescripts_BuildPackages.cmake) = 829c6140e952c2be59e0f2dc818d2dcdacca605d
-SHA1 (patch-release_Config.cmake.in) = 5ace40786e15b2dda7e7a62dbc7bcef262ebf2cb
 SHA1 (patch-simd_arm__aarch32_jsimdcpu.c) = 6251c6d9cc67980a754de2faaa4abb78eaaa9f1f
 SHA1 (patch-src_jpeglib.h) = 6be231604acd6a55f3a6d135cfaef20897e2926d