With -Wstringop-overflow enabled (which is now the default), GCC 12+
complains about the following code in jchuff.c:
/* Now count the number of symbols of each code length */
for (i = 0; i < num_nz_symbols; i++) {
/* The JPEG standard seems to think that this can't happen, */
/* but I'm paranoid... */
if (codesize[i] > MAX_CLEN)
ERREXIT(cinfo, JERR_HUFF_CLEN_OVERFLOW);
bits[codesize[i]]++;
}
and GCC 14+ complains about the following code in rdtarga.c:
/* Read next pixel */
for (i = 0; i < sinfo->pixel_size; i++) {
sinfo->tga_pixel[i] = (unsigned char)read_byte(sinfo);
}
Even a cursory read of the code shows that these warnings are obvious
false positives. I would normally be inclined to keep the warnings in
order to bring attention to this long-standing issue in GCC. However,
working around the issue necessitated disabling -Wstringop-overflow or
using GCC 11- in development builds, which might have masked legitimate
code issues.
Unfortunately, the GitHub security advisory system has become rife with
abuse. Not a single issue reported using that system has been a
legitimate security vulnerability. Rather, the reported issues have
fallen into the following categories:
- Blatant API abuse, sometimes due to AI-written test harnesses
A few of these exposed opportunities for API hardening, but none was
exploitable. Basically, if a program abused the API in the same way
as the aforementioned test harnesses, then the program could never
work with any image, and such a bug would never make it into the wild.
To put it another way, if a program calls:
unsigned char *buf1 = (unsigned char *)malloc(1);
unsigned char *buf2 = (unsigned char *)malloc(1);
memcpy(buf2, buf1, 2);
then that is not a security vulnerability in the C library. It is a
caller bug.
- Outright test harness bugs (e.g. failing to allocate enough memory for
a packed-pixel output buffer)
- Downstream bugs in other software
- Legitimate but unexploitable bugs in example code that is distributed
as part of the libjpeg-turbo documentation
- Potential but unconfirmed code quality issues reported by automated
tools (possibly bots, because none of the posters replied to followup
questions) against EOL versions of libjpeg-turbo
- One of the known issues reported in
https://libjpeg-turbo.org/pmwiki/uploads/About/TwoIssueswiththeJPEGStandard.pdf
(both of which are endemic to the progressive JPEG format but can be
worked around in both the libjpeg and TurboJPEG APIs)
- User confusion regarding the documented API behavior (which exposed
opportunities to clarify the documentation)
- Nonsensical spam by what appeared to be a bot account fishing for a
security patch reward
Unfortunately, with a high-profile project such as libjpeg-turbo,
certain "security researchers" try to use our project as a springboard
for self-promotion. They file draft security advisories on a knee-jerk
basis, in the hope that one of them will be accepted. Not once has
anyone who filed such a draft advisory demonstrated that they had
actually read our security policy.
Even more unfortunately, GitHub provides no way to make a draft security
advisory public without accepting it as a vulnerability. Thus, some
potentially useful information about the aforementioned issues has
remained hidden from the community. Honestly, I would have no problem
with the system if it simply allowed me to convert a draft security
advisory into a regular GitHub issue.
IMHO, the best way forward is to restrict the filing of draft security
advisories to project admins. The system is still active, and I can
still use it to file draft security advisories if there is a legitimate
need, but regular users will need to report the potential issue to me
first using another method.
Use stronger language in hopes that people will actually read it before
spamming the security advisory system. If not, then I may be forced to
disable private vulnerability reporting entirely.
AppVeyor ran our CI build when both branches and tags were pushed. This
is necessary to support signing with SignPath.io, since we only sign
releases and not pre-releases. However, due to an oversight in
9af8cca75c, the global on: dictionary
excluded tag pushes.
To simulate the previous AppVeyor CI environment:
- Run all jobs regardless of whether a branch or a tag was pushed.
- Use the if: key to exclude all jobs except "windows" from tag pushes.
The ubuntu-20.04 hosted runner image is going away on April 1, and newer
versions of Ubuntu can build but not run x32 binaries. The x32 ABI
seems to be mostly dead, but we can still regression test x32 support
using a local Ubuntu 20.04 VM if necessary. (That shouldn't be
necessary unless the x86-64 SIMD extensions change at some point in the
future.)
- Eliminate unnecessary "www."
- Use HTTPS.
- Update Java, MSYS, tdm-gcc, and NSIS URLs.
- Update URL and title of Agner Fog's assembly language optimization
manual.
- Remove extraneous information about MASM and Borland Turbo Assembler
and outdated NASM URLs from the x86 assembly headers, and mention
Yasm.
Referring to
https://sourceforge.net/p/libjpeg-turbo/bugs/48,
https://sourceforge.net/p/libjpeg-turbo/bugs/82,
#15, #238, #253, and #619,
valgrind and MSan have failed to properly detect data initialization by
libjpeg-turbo's x86 SIMD extensions for the entire 14 years that
libjpeg-turbo has been a project, resulting in false positives unless
libjpeg-turbo is built with WITH_SIMD=0 or run with JSIMD_FORCENONE=1.
This commit introduces a new C preprocessor macro (ZERO_BUFFERS) that,
if set, causes libjpeg-turbo to zero certain buffers in order to work
around the specific valgrind/MSan test failures caused by the
aforementioned false positives. This allows us to more closely
approximate the production configuration of libjpeg-turbo when testing
with valgrind or MSan.
Closes#781
If an error manager instance is passed to jpeg_std_error(), then its
format_message() method will point to the format_message() function in
jerror.c. The format_message() function passes all eight values from
the jpeg_error_mgr::msg_parm.i[] array as arguments to
snprintf()/_snprintf_s(), even if the format string doesn't use all of
those values. Subsequently invoking one of the ERREXIT[1-6]() macros
will leave the unused values uninitialized, and if the
-fsanitize-memory-param-retval option (introduced in Clang 14) is
enabled (which it is by default in Clang 16 and later), then MSan will
complain when the format_message() function tries to pass the
uninitialized-but-unused values as function arguments.
This commit modifies jpeg_std_error() so that it zeroes out the error
manager instance passed to it, thus working around the warning as well
as simplifying the code.
Closes#761
Referring to actions/runner-images#9491, the sanitizers in LLVM 14 that
ships with Ubuntu 22.04 are incompatible with high-entropy address space
layout randomization (ASLR), which is enabled in the GitHub runners via
their use of a newer kernel than ubuntu 22.04 uses.
- Detect at configure time, via the __CET__ C preprocessor macro,
whether the C compiler will include either indirect branch tracking
(IBT) or shadow stack support, and define a NASM macro (__CET__) if
so.
- Modify the x86-64 SIMD code so that it includes appropriate endbr64
instructions (to support IBT) and an appropriate .note.gnu.property
section (to support both IBT and shadow stack) when __CET__ is
defined.
Closes#350
Unfortunately, most of the GitHub security advisories filed against
libjpeg-turbo thus far have been the result of non-exploitable API
abuses triggered by randomly-generated test programs and accompanied by
wild claims of denials of service with no demonstrable or even probable
exploit that might cause such a DoS (assuming a service even existed
that used the API in question.) Security advisories remain private
unless accepted, and I cannot accept them if they do not describe an
actual security issue. Thus, it's best to steer most users toward
regular bug reports.
Because of bf01ed2fbc, the simd field in
huff_entropy_encoder (and, by extension, the simd field in
savable_state) is only initialized if WITH_SIMD is defined. Due to an
oversight, the simd field in savable_state was queried in flush_bits()
regardless of whether WITH_SIMD was defined. In most cases, both
branches of the query have identical code, and the optimizer removes the
branch. However, because the legacy Neon GAS Huffman encoder uses the
older bit buffer logic from libjpeg-turbo 2.0.x and prior (refer to
087c29e07f), the branches do not have
identical code when building for AArch64 with NEON_INTRINSICS undefined
(which will be the case if WITH_SIMD is undefined.) Thus, if
libjpeg-turbo was built for AArch64 with the SIMD extensions disabled
at build time, it was possible for the Neon GAS branch in flush_bits()
to be taken, which would have set put_bits to a value that is incorrect
for the C Huffman encoder. Referring to #728, a user reported that this
issue sometimes caused libjpeg-turbo to generate bogus JPEG images if it
was built for AArch64 without SIMD extensions and subsequently used
through the Qt framework. (It should be noted, however, that disabling
the SIMD extensions in AArch64 builds of libjpeg-turbo is inadvisable
for performance reasons.)
I was unable to reproduce the issue on Linux/AArch64 using libjpeg-turbo
alone, despite testing various versions of GCC and Clang and various
optimization levels. However, the issue is reproducible using MSan with
-O0, so this commit also modifies the GitHub Actions workflow so that
compiler optimization is disabled in the linux-msan job. That should
prevent the issue or similar issues from re-emerging.
Fixes#728
- Clarify that encrypted e-mail is optional.
- Mention the new GitHub security advisory system.
- Clarify that vulnerabilities against new features that are not yet in
a Stable release series need not be reported securely.
In libjpeg-turbo 2.1.x and prior, the WITH_12BIT CMake variable was used
to enable 12-bit JPEG support at compile time, because the libjpeg API
library could not handle multiple JPEG data precisions at run time. The
initial approach to handling multiple JPEG data precisions at run time
(7fec5074f9) created a whole new API,
library, and applications for 12-bit data precision, so it made sense to
repurpose WITH_12BIT to allow 12-bit data precision to be disabled.
e8b40f3c2b made it so that the libjpeg API
library can handle multiple JPEG data precisions at run time via a
handful of straightforward API extensions. Referring to
6c2bc901e2, it hasn't been possible to
build libjpeg-turbo with both forward and backward libjpeg API/ABI
compatibility since libjpeg-turbo 1.4.x. Thus, whereas we retain full
backward API/ABI compatibility with libjpeg v6b-v8, forward libjpeg
API/ABI compatibility ceased being realistic years ago, so it no longer
makes sense to provide compile-time options that give a false sense of
forward API/ABI compatibility by allowing some (but not all) of our
libjpeg API extensions to be disabled. Such options are difficult to
maintain and clutter the code with #ifdefs.
Referring to the conversation in
https://github.com/google/oss-fuzz/issues/7479 and #559, there was a
misunderstanding regarding how CIFuzz works. It cannot be used to fuzz
arbitrary PRs or code branches, and it has a 90-day delay in downloading
corpora from OSS-Fuzz. That makes it unsuitable for libjpeg-turbo.
With x86-64 builds, the default value of FLOATTEST works with both the
8-bit-per-sample and 12-bit-per-sample flavors of the libjpeg API
library. However, that is not the case with x86 builds. Thus, we need
separate 8-bit-per-sample and 12-bit-per-sample FLOATTEST variables.
