|
6abd3916
|
2016-11-15T08:47:43
|
|
Unified CMake-based build system
See #56 for discussion.
Fixes #21, Fixes #29, Fixes #37, Closes #56, Fixes #58, Closes #73
Obviates #82
See also:
https://sourceforge.net/p/libjpeg-turbo/feature-requests/5/
https://sourceforge.net/p/libjpeg-turbo/patches/5/
|
|
|
0ff7da71
|
2016-11-16T15:55:12
|
|
Advertise the new AVX2 SIMD extensions
(our story so far ...)
|
|
|
74e4c793
|
2016-11-16T15:08:16
|
|
TJBench: Fix regression/-nowrite always enabled
Introduced by eb59b6e72d8098a1f7b8c7e0c710b32eb6f5dc45
|
|
|
7bfb22af
|
2016-09-26T17:59:14
|
|
Fix broken MIPS build
Regression introduced by 9055fb408dcb585ce9392d395e16630d51002152
Fixes #104
|
|
|
dfefba77
|
2016-09-22T14:19:29
|
|
Fix broken build with NDK platforms < android-21
Regression introduced by a09ba29a55b9a43d346421210d94370065eeaf53
Fixes #103
|
|
cb88e5da
|
2016-09-20T21:06:24
|
|
ARM64 NEON: Fix another ABI conformance issue
Based on
https://github.com/mayeut/libjpeg-turbo/commit/98a5a9dc899aa9265858a3cbe0a96289a31a1322
with wordsmithing by DRC.
In the AArch64 ABI, as in many others, it's forbidden to read/store data
below the stack pointer. Some SIMD functions were doing just that
(stack pointer misuse) when trying to preserve callee-saved registers,
and this resulted in those registers being restored with incorrect
contents under certain circumstances.
This patch fixes that behavior, and callee-saved registers are now
stored above the stack pointer throughout the function call. The patch
also removes register saving in places where it is unnecessary for this
ABI, or it makes use of unused scratch regiters instead of callee-saved
registers.
Fixes #97. Closes #101.
Refer also to https://bugzilla.redhat.com/show_bug.cgi?id=1368569
|
|
|
077e5bb4
|
2016-09-08T21:49:02
|
|
Fix out-of-bounds write in partial decomp. feature
Reported by Clang UBSan (refer to
https://bugzilla.mozilla.org/show_bug.cgi?id=1301252 for test image.)
This appears to be a legitimate bug introduced by
3ab68cf563f6edc2608c085f5c8b2d5d5c61157e. Any component array, such
as first_MCU_col and last_MCU_col, should always be able to accommodate
MAX_COMPONENTS values. The aforementioned test image had 8 components,
which was not enough to make the out-of-bounds write bust out of the
jpeg_decomp_master struct (and fortunately the memory after last_MCU_col
is an integer used as a boolean, so stomping on it will do nothing other
than change the decoder state.) I crafted another special image that
has 10 components (the maximum allowable), but that was apparently not
enough to bust out of the allocated memory, either. Thus, it is
posited that the security threat posed by this bug is either extremely
minimal or non-existent.
|
|
|
a1dd3568
|
2016-09-08T21:29:58
|
|
Silence additional UBSan warnings
NOTE: The jdhuff.c/jdphuff.c warnings should have already been silenced
by 8e9cef2e6f5156c4b055a04a8f979b7291fc6b7a, but apparently I need to
be REALLY clear that I'm trying to do pointer arithmetic rather than
dereference an array. Grrr...
Refer to:
https://bugzilla.mozilla.org/show_bug.cgi?id=1301250
https://bugzilla.mozilla.org/show_bug.cgi?id=1301256
|
|
|
a09ba29a
|
2016-09-07T16:40:10
|
|
Fix unsigned int overflow in libjpeg memory mgr.
When attempting to decode a malformed JPEG image (refer to
https://bugzilla.mozilla.org/show_bug.cgi?id=1295044) with dimensions
61472 x 32800, the maximum_space variable within the
realize_virt_arrays() function will exceed the maximum value of a 32-bit
integer and will wrap around. The memory manager subsequently fails
with an "Insufficient memory" error (case 4, in alloc_large()), so this
commit simply causes that error to be triggered earlier, before UBSan
has a chance to complain.
Note that this issue did not ever represent an exploitable security
threat, because the POSIX-based memory manager that we use doesn't ever
do anything meaningful with the value of maximum_space.
jpeg_mem_available() simply sets avail_mem = maximum_space, so the
subsequent behavior of the memory manager is the same regardless of
whether maximum_space is correct or not. This commit simply removes a
UBSan warning in order to make it easier to detect actual security
issues.
|
|
|
8ce2c911
|
2016-08-01T11:22:24
|
|
TurboJPEG: Decomp. 4:2:2/4:4:0 JPEGs w/unusual SFs
Normally, 4:2:2 JPEGs have horizontal x vertical luminance,chrominance
sampling factors of 2x1,1x1, and 4:4:0 JPEGs have horizontal x vertical
luminance,chrominance sampling factors of 1x2,1x1. However, it is
technically legal to create 4:2:2 JPEGs with sampling factors of
2x2,1x2 and 4:4:0 JPEGs with sampling factors of 2x2,2x1, since the
sums of the products of those sampling factors (2x2 + 1x2 + 1x2 and
2x2 + 2x1 + 2x1) are still <= 10. The libjpeg API correctly decodes
such images, so the TurboJPEG API should as well.
Fixes #92
|
|
|
7723d7f7
|
2016-07-13T20:39:11
|
|
Use plain upsampling if merged isn't accelerated
Currently, this only affects ARM, since it is the only platform that
accelerates YCbCr-to-RGB conversion but not merged upsampling. Even if
"plain" upsampling isn't accelerated, the combination of accelerated
color conversion + unaccelerated plain upsampling is still faster than
the unaccelerated merged upsampling algorithms.
Closes #81
|
|
628c168c
|
2016-07-10T19:01:51
|
|
Implement h1v2 fancy upsampling
This allows fancy upsampling to be used when decompressing 4:2:2 images
that have been losslessly rotated or transposed.
(docs and comments added by DRC)
Based on https://github.com/pornel/libjpeg-turbo/commit/f63aca945debde07e7c6476a1f667b71728c3d44
Closes #89
|
|
|
1120ff29
|
2016-07-13T12:15:02
|
|
Fix AArch64 ABI conformance issue in SIMD code
In the AArch64 ABI, the high (unused) DWORD of a 32-bit argument's
register is undefined, so it was incorrect to use 64-bit
instructions to transfer a JDIMENSION argument in the 64-bit NEON SIMD
functions. The code worked thus far only because the existing compiler
optimizers weren't smart enough to do anything else with the register in
question, so the upper 32 bits happened to be all zeroes.
The latest builds of Clang/LLVM have a smarter optimizer, and under
certain circumstances, it will attempt to load-combine adjacent 32-bit
integers from one of the libjpeg structures into a single 64-bit integer
and pass that 64-bit integer as a 32-bit argument to one of the SIMD
functions (which is allowed by the ABI, since the upper 32 bits of the
32-bit argument's register are undefined.) This caused the
libjpeg-turbo regression tests to crash.
This patch tries to use the Wn registers whenever possible. Otherwise,
it uses a zero-extend instruction to avoid using the upper 32 bits of
the 64-bit registers, which are not guaranteed to be valid for 32-bit
arguments.
Based on https://github.com/sebpop/libjpeg-turbo/commit/1fbae13021eb98f6fffdfaf8678fcdb00b0b04d9
Closes #91. Refer also to android-ndk/ndk#110 and
https://llvm.org/bugs/show_bug.cgi?id=28393
|
|
|
6e9d43e0
|
2016-07-06T16:58:28
|
|
Linux/PPC: Only enable AltiVec if CPU supports it
This eliminates "illegal instruction" errors when running libjpeg-turbo
under Linux on PowerPC chips that lack AltiVec support (e.g. the old
7XX/G3 models but also the newer e5500 series.)
|
|
|
9055fb40
|
2016-07-07T13:10:30
|
|
ARM/MIPS: Change the behavior of JSIMD_FORCE*
The JSIMD_FORCE* environment variables previously meant "force the use
of this instruction set if it is available but others are available as
well", but that did nothing on ARM platforms, since there is only ever
one instruction set available. Since the ARM and MIPS CPU feature
detection code is less than bulletproof, and since there is only one
SIMD instruction set (currently) supported on those platforms, it makes
sense for the JSIMD_FORCE* environment variables on those platforms to
actually force the use of the SIMD instruction set, thus bypassing the
CPU feature detection code.
This addresses a concern raised in #88 whereby parsing /proc/cpuinfo
didn't work within a QEMU environment. This at least provides a
workaround, allowing users to force-enable or force-disable SIMD
instructions for ARM and MIPS builds of libjpeg-turbo.
|
|
|
68cf83db
|
2016-05-10T21:04:02
|
|
Don't allow opaque source/dest mgrs to be swapped
Calling jpeg_stdio_dest() followed by jpeg_mem_dest(), or jpeg_mem_src()
followed by jpeg_stdio_src(), is dangerous, because the existing opaque
structure would not be big enough to accommodate the new source/dest
manager. This issue was non-obvious to libjpeg-turbo consumers, since
it was only documented in code comments. Furthermore, the issue could
also occur if the source/dest manager was allocated by the calling
program, but it was not allocated with enough space to accommodate the
opaque stdio or memory source/dest manager structs. The safest thing to
do is to throw an error if one of these functions is called when there
is already a source/dest manager assigned to the object and it was
allocated elsewhere.
Closes #78, #79
|
|
5e576386
|
2016-05-02T12:31:51
|
|
ARMv7 SIMD: Fix clang compatibility
By design, clang only supports Unified Assembler Language (and not
pre-UAL syntax):
https://llvm.org/bugs/show_bug.cgi?id=23507
http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.dui0473c/BABJIHGJ.html
Thus, clang only supports the strbeq instruction and not streqb, but
unfortunately some versions of GCC only support streqb. Go, go
Gadget #ifdef...
Based on https://github.com/mattsarett/libjpeg-turbo/commit/a82e63aac63f8fa3
95fa4caad4de6859623ee2e2
Closes #75
|
|
|
1959e28b
|
2016-04-21T10:22:36
|
|
Increase severity of tjDecompressToYUV2() bug desc
Actually, what happened was that the longjmp() call within
my_error_exit() acted on the previous value of myerr->setjmp_buffer,
which was probably set in a previous TurboJPEG function, such as
tjInitDecompress(). Thus, when a libjpeg error was triggered within
the body of tjDecompressToYUV2(), the PC jumped to the error handler
of the previous TurboJPEG function, and this usually caused stack
corruption in the calling program (because the signature and return
type of the previous TurboJPEG function probably wasn't the same.)
|
|
|
dec79952
|
2016-04-20T11:27:42
|
|
Catch libjpeg errors in tjDecompressToYUV2()
Even though tjDecompressToYUV2() is mostly just a wrapper for
tjDecompressToYUVPlanes(), tjDecompressToYUV2() still calls
jpeg_read_header(), so it needs to properly set up the libjpeg error
handler prior to making this call. Otherwise, under very esoteric (and
arguably incorrect) use cases, a program can call tjDecompressToYUV2()
without first checking the JPEG header using tjDecompressHeader3(), and
if the header is corrupt, tjDecompressToYUV2() will abort without
triggering an error.
Fixes #72
|
|
|
1a3aebd8
|
2016-03-31T10:02:44
|
|
Merge branch '1.4.x'
|
|
|
b2817f52
|
2016-03-16T07:18:30
|
|
Merge branch '1.4.x'
|
|
|
1385f8b2
|
2016-03-14T13:32:00
|
|
ChangeLog.md: Improve readability of plain text
|
|
|
a839a7a9
|
2016-03-13T16:24:48
|
|
Markdown version of ChangeLog.txt
This will make it easier to crib ChangeLog information into release
notes, since both SourceForge and GitHub support MD.
|
|
|
3f56bd59
|
2016-03-13T12:36:06
|
|
Rename ChangeLog.txt
... in preparation for creating a MarkDown version (Git will not
preserve history unless you rename the file prior to modifying it.)
|