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.4.1
Date: Sun, 26 Apr 2026 13:44:11 +0200 [thread overview]
Message-ID: <20260426114418.122889-22-adolf.belka@ipfire.org> (raw)
In-Reply-To: <20260426114418.122889-1-adolf.belka@ipfire.org>
- Update from version 3.1.3 to 3.1.4.1
- No change to rootfile
- Changelog
3.1.4.1
1. Fixed multiple issues, some long-standing and some that were regressions
introduced in 3.1.4, that made the CMake package config files non-relocatable
and broke the `--prefix` option to `cmake --install`.
3.1.4
1. Fixed an issue in the TurboJPEG 2.x compatibility wrapper whereby, if a
calling program attempted to decompress a lossless JPEG image using
`tjDecompress2()` with decompression scaling, the decompressed image was
unexpectedly unscaled. This could have led to a buffer overrun if the caller
allocated the packed-pixel destination buffer based on the assumption that the
decompressed image would be scaled down.
2. The SIMD dispatchers now use `getauxval()` or `elf_aux_info()`, if
available, to detect support for Neon and AltiVec instructions on AArch32 and
PowerPC Linux, Android, and *BSD systems.
3. Hardened the libjpeg API against hypothetical applications that may
erroneously set one of the exposed quantization table values to 0 just before
calling `jpeg_start_compress()`. (This would never happen in a
correctly-written program, because `jpeg_add_quant_table()` clamps all values
less than 1.)
4. Fixed a division-by-zero error that occurred when attempting to use the
jpegtran `-drop` option with a specially-crafted malformed drop image
(specifically an image in which one or more of the quantization table values
was 0.)
5. Fixed an issue in the TurboJPEG API library's data destination manager that
manifested as:
- a memory leak that occurred if a pre-allocated JPEG destination buffer
was passed to `tj3Compress*()` or `tj3Transform()`, `TJPARAM_NOREALLOC` was
unset, and it was necessary for the library to re-allocate the buffer to
accommodate the destination image, and
- a potential caller double free that occurred if pre-allocated JPEG
destination buffers were passed to `tj3Transform()`, multiple lossless
transform operations were performed, and it was necessary for the library to
re-allocate the second buffer to accommodate the second destination image.
6. Fixed an issue in `tj3Transform()` whereby, if `TJPARAM_SAVEMARKERS` was set
to 2 or 4, `TJXOPT_COPYNONE` was not specified, an ICC profile was extracted
from the source image, and another ICC profile was associated with the
TurboJPEG instance using `tj3SetICCProfile()`, both profiles were embedded in
the destination image. The documented API behavior is for `TJXOPT_COPYNONE` to
take precedence over `TJPARAM_SAVEMARKERS` and for `TJPARAM_SAVEMARKERS` to
take precedence over the associated ICC profile. Thus, `tj3Transform()` now
ignores the associated ICC profile unless `TJXOPT_COPYNONE` is specified or
`TJPARAM_SAVEMARKERS` is set to something other than 2 or 4.
7. Fixed an oversight in the libjpeg API whereby, if a calling application
manually set `cinfo.Ss` (the predictor selection value) to a value less than 1
or greater than 7 after calling `jpeg_enable_lossless()` and prior to calling
`jpeg_start_compress()`, an incorrect (all white) lossless JPEG image was
silently generated.
8. Further hardened the TurboJPEG Java API against hypothetical applications
that may erroneously pass huge values to one of the compression, YUV encoding,
decompression, YUV decoding, or packed-pixel image I/O methods, leading to
signed integer overflow in the JNI wrapper's buffer size checks that rendered
those checks ineffective.
Signed-off-by: Adolf Belka <adolf.belka@ipfire.org>
---
lfs/libjpeg | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/lfs/libjpeg b/lfs/libjpeg
index da4c04536..b03f795cf 100644
--- a/lfs/libjpeg
+++ b/lfs/libjpeg
@@ -24,7 +24,7 @@
include Config
-VER = 3.1.3
+VER = 3.1.4.1
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 = 3c675aa56b3474ca8a27f355d14dd7411d90471564c5916884e87818b7165e73a6c6b416dc2800e31c10dd1390ae88353e81d80eceb2e22c00b6a81ac5cf3d65
+$(DL_FILE)_BLAKE2 = 7e38379b4e3bb168e6ec081be5852f9a7f4680929d42e5cccb0c00632130eee9200afdc9c2ed99250c3ddfc1cd8dd21f60da54e6c48157884c9173ae1b3f9a9f
install : $(TARGET)
--
2.54.0
next prev parent reply other threads:[~2026-04-26 11:44 UTC|newest]
Thread overview: 29+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-04-26 11:43 [PATCH] core202: Ship coreutils Adolf Belka
2026-04-26 11:43 ` [PATCH] core202: Ship glib Adolf Belka
2026-04-26 11:43 ` [PATCH] core202: Ship hwdata Adolf Belka
2026-04-26 11:43 ` [PATCH] core202: Ship iproute2 Adolf Belka
2026-04-26 11:43 ` [PATCH] core202: Ship libcap Adolf Belka
2026-04-26 11:43 ` [PATCH] core202: Ship libgcrypt Adolf Belka
2026-04-26 11:43 ` [PATCH] core202: Ship libjpeg Adolf Belka
2026-04-26 11:43 ` [PATCH] core202: Ship libxml2 Adolf Belka
2026-04-26 11:43 ` [PATCH] core202: Ship parted Adolf Belka
2026-04-26 11:43 ` [PATCH] core202: Ship texinfo Adolf Belka
2026-04-26 11:44 ` [PATCH] coreutils: Update to version 9.11 Adolf Belka
2026-04-26 11:44 ` [PATCH] git: Update to version 2.54.0 Adolf Belka
2026-04-26 11:44 ` [PATCH] glib: Update to version 2.88.0 Adolf Belka
2026-04-26 11:44 ` [PATCH] harfbuzz: Update to version 14.2.0 Adolf Belka
2026-04-26 11:44 ` [PATCH] hwdata: Update to version 0.406 Adolf Belka
2026-04-26 11:44 ` [PATCH] iana-etc: Update to version 20260409 Adolf Belka
2026-04-26 11:44 ` [PATCH] iperf3: Update to version 3.21 Adolf Belka
2026-04-26 11:44 ` [PATCH] iproute2: Update to version 7.0.0 Adolf Belka
2026-04-26 11:44 ` [PATCH] libcap-ng: Update to version 0.9.3 Adolf Belka
2026-04-26 11:44 ` [PATCH] libcap: Update to version 2.78 Adolf Belka
2026-04-26 11:44 ` [PATCH] libgcrypt: Update to version 1.12.2 Adolf Belka
2026-04-26 11:44 ` Adolf Belka [this message]
2026-04-26 11:44 ` [PATCH] libmpc: Update to version 1.4.1 Adolf Belka
2026-04-26 11:44 ` [PATCH] libpng: Update to version 1.6.58 Adolf Belka
2026-04-26 11:44 ` [PATCH] libsodium: Update to version 1.0.22 Adolf Belka
2026-04-26 11:44 ` [PATCH] libxml2: Update to version 2.15.3 Adolf Belka
2026-04-26 11:44 ` [PATCH] parted: Update to version 3.7 Adolf Belka
2026-04-26 11:44 ` [PATCH] pciutils: Update to version 3.15.0 Adolf Belka
2026-04-26 11:44 ` [PATCH] texinfo: Update to version 7.3 Adolf Belka
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=20260426114418.122889-22-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