From: Adolf Belka <adolf.belka@ipfire.org>
To: development@lists.ipfire.org
Cc: Adolf Belka <adolf.belka@ipfire.org>
Subject: [PATCH] libjpeg: Update to version 3.1.3
Date: Tue, 20 Jan 2026 17:33:11 +0100 [thread overview]
Message-ID: <20260120163311.3763307-9-adolf.belka@ipfire.org> (raw)
In-Reply-To: <20260120163311.3763307-1-adolf.belka@ipfire.org>
- Update from version 3.1.1 to 3.1.3
- No change to rootfile
- Changelog
3.1.3
Significant changes relative to 3.1.2:
1. Hardened the TurboJPEG API against hypothetical applications that may
erroneously call `tj*Compress*()` or `tj*Transform()` with a reused JPEG
destination buffer pointer while specifying a destination buffer size of 0.
2. Hardened the TurboJPEG API against hypothetical applications that may
erroneously set `TJPARAM_LOSSLESS` or `TJPARAM_COLORSPACE` prior to calling
`tj3EncodeYUV*8()` or `tj3CompressFromYUV*8()`. `tj3EncodeYUV*8()` and
`tj3CompressFromYUV*8()` now ignore `TJPARAM_LOSSLESS` and
`TJPARAM_COLORSPACE`.
3. Hardened the TurboJPEG Java API against hypothetical applications that may
erroneously pass huge X or Y offsets to one of the compression, YUV encoding,
decompression, or YUV decoding methods, leading to signed integer overflow in
the JNI wrapper's buffer size checks that rendered those checks ineffective.
4. Fixed an issue in the TurboJPEG Java API whereby
`TJCompressor.getSourceBuf()` sometimes returned the buffer from a previous
invocation of `TJCompressor.loadSourceImage()` if the target data precision was
changed before the most recent invocation.
5. Fixed an issue in the PPM reader that caused incorrect pixels to be
generated when using `tj3LoadImage*()` or `TJCompressor.loadSourceImage()` to
load a PBMPLUS (PPM/PGM) file into a CMYK buffer with a different data
precision than that of the file.
3.1.2
Significant changes relative to 3.1.1:
1. Fixed a regression introduced by 3.1 beta1[5] that caused a segfault in
TJBench if `-copy` or `-c` was passed as the last command-line argument.
2. The build system now uses wrappers rather than CMake object libraries to
compile source files for multiple data precisions. This improves code
readability and facilitates adapting the libjpeg-turbo source code to non-CMake
build systems.
3. Fixed an issue whereby decompressing a 4:2:0 or 4:2:2 JPEG image with merged
upsampling disabled/one-pass color quantization enabled, then reusing the same
API instance to decompress a 4:2:0 or 4:2:2 JPEG image with merged upsampling
enabled/color quantization disabled, caused `jpeg_skip_scanlines()` to use
freed memory. In practice, the freed memory was not reclaimed before it was
used. Thus, this issue did not cause a segfault or other user-visible errant
behavior (it was only detectable with ASan), and it did not likely pose a
security risk.
4. The AArch64 (Arm 64-bit) Neon SIMD extensions and accelerated Huffman codec
now support the Arm64EC ABI on Windows, which allows Windows/x64 applications
to call native Arm64 functions when running under the Windows/x64 emulator on
Windows/Arm.
Signed-off-by: Adolf Belka <adolf.belka@ipfire.org>
---
lfs/libjpeg | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/lfs/libjpeg b/lfs/libjpeg
index a2fbea304..da4c04536 100644
--- a/lfs/libjpeg
+++ b/lfs/libjpeg
@@ -1,7 +1,7 @@
###############################################################################
# #
# IPFire.org - A linux based firewall #
-# Copyright (C) 2007-2025 IPFire Team <info@ipfire.org> #
+# Copyright (C) 2007-2026 IPFire Team <info@ipfire.org> #
# #
# This program is free software: you can redistribute it and/or modify #
# it under the terms of the GNU General Public License as published by #
@@ -24,7 +24,7 @@
include Config
-VER = 3.1.1
+VER = 3.1.3
THISAPP = libjpeg-turbo-$(VER)
DL_FILE = $(THISAPP).tar.gz
@@ -40,7 +40,7 @@ objects = $(DL_FILE)
$(DL_FILE) = $(DL_FROM)/$(DL_FILE)
-$(DL_FILE)_BLAKE2 = 813781b1c91ed132b2d1b6e3d7834673e202765362cc9e77a6e7d4a92e89c0192312405ae8197e1c306ad3c89e23cd6dc5e418bb9f3570f110014ab79f717401
+$(DL_FILE)_BLAKE2 = 3c675aa56b3474ca8a27f355d14dd7411d90471564c5916884e87818b7165e73a6c6b416dc2800e31c10dd1390ae88353e81d80eceb2e22c00b6a81ac5cf3d65
install : $(TARGET)
--
2.52.0
prev parent reply other threads:[~2026-01-20 16:33 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-01-20 16:33 [PATCH] alsa: Update to version 1.2.15.3 Adolf Belka
2026-01-20 16:33 ` [PATCH] core200: Ship curl Adolf Belka
2026-01-20 16:33 ` [PATCH] core200: Ship libcap-ng Adolf Belka
2026-01-20 16:33 ` [PATCH] core200: Ship libjpeg Adolf Belka
2026-01-20 16:33 ` [PATCH] curl: Update to version 8.18.0 Adolf Belka
2026-01-20 16:33 ` [PATCH] hwdata: Update to version 0.403 Adolf Belka
2026-01-20 16:33 ` [PATCH] libarchive: Update to version 3.8.5 Adolf Belka
2026-01-20 16:33 ` [PATCH] libcap-ng: Update to version 0.9 Adolf Belka
2026-01-20 16:33 ` Adolf Belka [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20260120163311.3763307-9-adolf.belka@ipfire.org \
--to=adolf.belka@ipfire.org \
--cc=development@lists.ipfire.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox