kc3-lang/libjpeg-turbo/src
Branch :
Log
| Author | Commit | Date | CI | Message |
|---|---|---|---|---|
 |
f74989d8 | 2025-09-25 11:32:45 | Clean up #include directives This is subtle, but #include <header.h> searches directories specified with -I, then system include directories. #include "header.h" searches the current source directory, then directories specified with -I, then system include directories. Using bracketed #include directives for jpeglib.h, jinclude.h, jerror.h, cdjpeg.h, and turbojpeg.h only worked because the build system explicitly passed -I{source_directory}/src/ to the compiler. Referring to 51cee0362998ec6f1eabac1e795f3b6e3ee639ea, it's better for the source code to have as few dependencies on our specific build system as possible. Since jpeglib.h, jinclude.h, jerror.h, and turbojpeg.h can be installed in system include directories, it's also better for internal references to those headers to resolve internally first, to avoid potential conflicts between the system-installed version of libjpeg-turbo and the version being built. (Such conflicts would never have occurred with our build system, but they might have occurred due to misintegration with a downstream build system.) | |
|
98c45838 | 2025-08-21 11:22:51 | Fix issues with Windows Arm64EC builds Arm64EC basically wraps native Arm64 functions with an emulated Windows/x64 ABI, which can improve performance for Windows/x64 applications running under the x64 emulator on Windows/Arm. When building for Arm64EC, the compiler defines _M_X64 and _M_ARM64EC but not _M_ARM64. | |
|
f158143e | 2025-07-28 20:45:02 | jpeg_skip_scanlines: Fix UAF w/merged upsamp/quant jpeg_skip_scanlines() (more specifically, read_and_discard_scanlines()) should check whether merged upsampling is disabled before attempting to dereference cinfo->cconvert, and it should check whether color quantization is enabled before attempting to dereference cinfo->cquantize. Otherwise, executing one of the following sequences with the same libjpeg API instance and any 4:2:0 or 4:2:2 JPEG image will cause a use-after-free issue: - Disable merged upsampling (default) - jpeg_start_decompress() - jpeg_finish_decompress() (frees but doesn't zero cinfo->cconvert) - Enable merged upsampling - jpeg_start_decompress() (doesn't re-allocate cinfo->cconvert, because j*init_color_deconverter() isn't called) - jpeg_skip_scanlines() - Enable 1-pass color quantization - jpeg_start_decompress() - jpeg_finish_decompress() (frees but doesn't zero cinfo->cquantize) - Disable 1-pass color quantization - jpeg_start_decompress() (doesn't re-allocate cinfo->cquantize, because j*init_*_quantizer() isn't called) - jpeg_skip_scanlines() These sequences are very unlikely to occur in a real-world application. In practice, this issue does not even cause a segfault or other user-visible errant behavior, so it is only detectable with ASan. That is because the memory region is small enough that it doesn't get reclaimed by either the application or the O/S between the point at which it is freed and the point at which it is used (even though a subsequent malloc() call requests exactly the same amount of memory.) Thus, this is an undefined behavior issue, but it is unlikely to be exploitable. | |
|
51cee036 | 2025-06-13 14:52:09 | Build: Use wrappers rather than CMake object libs Some downstream projects need to adapt the libjpeg-turbo source code to non-CMake build systems, and the use of CMake object libraries made that difficult. Referring to #754, the use of CMake object libraries also caused the libjpeg-turbo libraries to contain duplicate object names, which caused problems with certain development tools. This commit modifies the build system so that it uses wrappers, rather than CMake object libraries, to compile source files for multiple data precisions. For convenience, the wrappers are included in the source tree, but they can be re-generated by building the "wrappers" target. In addition to facilitating downstream integration, using wrappers improves code readability, since multiple data precisions are now handled at the source code level instead of at the build system level. Since this will be pushed to a bug-fix release, the goal was to avoid changing any existing source code. A future major release of libjpeg-turbo may restructure the libjpeg API source code so that only the functions that need to be compiled for multiple data precisions are wrapped. (That is how the TurboJPEG API source code is structured.) Closes #817 | |
|
c889b1da | 2025-06-12 09:40:20 | TJBench: Require additional argument with -copy (oversight from e4c67aff50420d7bacff503ceb4556c896128413) | |
|
66771223 | 2025-05-13 10:33:15 | cjpeg: Free ICC profile if API error when fuzzing Fixes #809 | |
|
e0e18dea | 2024-12-18 12:50:38 | Ensure methods called by global funcs are init'd If a hypothetical calling application does something really stupid and changes cinfo->data_precision after calling jpeg_start_*compress(), then the precision-specific methods called by jpeg_write_scanlines(), jpeg_write_raw_data(), jpeg_finish_compress(), jpeg_read_scanlines(), jpeg_read_raw_data(), or jpeg_start_output() may not be initialized. Ensure that the first precision-specific method (which will always be cinfo->main->process_data*(), cinfo->coef->compress_data*(), or cinfo->coef->decompress_data()) called by any global function that may be called after jpeg_start_*compress() is initialized and non-NULL. This increases the likelihood (but does not guarantee) that a hypothetical stupid calling application will fail gracefully rather than segfault if it changes cinfo->data_precision after calling jpeg_start_*compress(). A hypothetical stupid calling application can still bork itself by changing cinfo->data_precision after initializing the source manager but before calling jpeg_start_compress(), or after initializing the destination manager but before calling jpeg_start_decompress(). | |
|
84fa3bc0 | 2024-12-11 17:39:02 | tjTransform(): Fix false positive compiler warning | |
|
9758c8a7 | 2024-11-18 13:40:08 | Exclude more code if !(C|D)_LOSSLESS_SUPPORTED | |
|
d7932a27 | 2024-10-30 12:12:03 | TJ doc: Density params require YCbCr or grayscale Since libjpeg-turbo does not support Exif, the only way it can embed density information in a JPEG image is by using the JFIF marker, which is only written if the JPEG colorspace is YCbCr or grayscale. (Referring to the conversation under #793, we may need to further restrict that to 8-bit-per-sample JPEG images, because the JFIF spec requires 8-bit data precision.) |