kmx git

Commit	Date	Message
6d48aaac	2025-10-22T10:30:53	TJ: Handle lossless/CS params w/ YUV enc/compress - If TJPARAM_LOSSLESS was set, then tj3EncodeYUV8() called jpeg_enable_lossless() (via setCompDefaults()), which caused the underlying libjpeg API to silently disable subsampling and color conversion. This led to three issues: 1. Attempting to encode RGB pixels produced incorrect YCbCr or grayscale components, since color conversion did not occur. The same issue occurred if TJPARAM_COLORSPACE was explicitly set to TJCS_RGB. 2. Attempting to encode RGB pixels into a grayscale plane caused tj3EncodeYUVPlanes8() to overflow the caller's destination pointer array if the array was not big enough to accommodate three pointers. If called from tj3EncodeYUV8(), tj3EncodeYUVPlanes8() did not overflow the caller's destination pointer array, but a segfault occurred when it attempted to copy to the Cb and Cr pointers, which were NULL. The same issue occurred if TJPARAM_COLORSPACE was explicitly set to anything other than TJCS_GRAY. 3. Attempting to encode RGB pixels into subsampled YUV planes caused tj3EncodeYUV8() to overflow the caller's buffer(s) if the buffer(s) were not big enough to accommodate 4:4:4 (non-subsampled) YUV planes. That would have been the case if the caller allocated its buffer(s) based on the return value of tj3YUVBufSize() or tj3YUVPlaneSize(). The same issue occurs if TJPARAM_SUBSAMP is explicitly set to TJSAMP_444. tj3EncodeYUV8() now ignores TJPARAM_LOSSLESS and TJPARAM_COLORSPACE. - If TJPARAM_LOSSLESS was set, then attempting to compress a grayscale plane into a JPEG image caused tj3CompressFromYUVPlanes8() to overflow the caller's source pointer array if the array was not big enough to accommodate three pointers. If called from tj3CompressFromYUV8(), tj3CompressFromYUVPlanes8() did not overflow the caller's source pointer array, but a segfault occurred when it attempted to copy from the Cb and Cr pointers, which were NULL. This was similar to Issue 2 above. The same issue occurred if TJPARAM_COLORSPACE was explicitly set to anything other than TJCS_GRAY. tj3CompressFromYUV8() now throws an error if TJPARAM_LOSSLESS is set, and it now ignores TJPARAM_COLORSPACE. These issues did not pose a security risk, since security exploits involve supported workflows that function normally except when supplied with malformed input data. It is documented that colorspace conversion, chrominance subsampling, and compression from planar YUV images are unavailable when TJPARAM_LOSSLESS is set. When TJPARAM_LOSSLESS is set, the library effectively sets TJPARAM_SUBSAMP to TJSAMP_444 and TJPARAM_COLORSPACE to TJCS_RGB, TJCS_GRAY, or TJCS_CMYK, depending on the pixel format of the source image. That behavior is strongly implied by the documentation of TJPARAM_LOSSLESS, although the documentation isn't specific about whether TJPARAM_LOSSLESS applies to tj3EncodeYUV8(). In any case, setting TJPARAM_LOSSLESS before calling tj3CompressFromYUV8() was never a supported or functional workflow, and setting TJPARAM_LOSSLESS before calling tj3EncodeYUV*8() was never a functional workflow. Thus, there should be no applications "in the wild" that use either workflow. Such applications would crash every time they attempted to encode to or compress from a YUV image. In other words, setting TJPARAM_LOSSLESS or TJPARAM_COLORSPACE required the caller to understand the ramifications of the loss of color conversion and/or subsampling, and failing to do so was essentially API abuse (albeit subtle API abuse, hence the desire to make the behavior more intuitive.) This commit also removes no-op code introduced by 6da05150efa9b7a190d05bf82295127c778d15ab. Since setCompDefaults() returns after calling jpeg_enable_lossless(), modifying the subsampling level locally had no effect. The libjpeg API already silently disables subsampling in jinit_c_master_control() if lossless compression is enabled, so it was not necessary for setCompDefaults() to handle that. Fixes #839
1f3614f1	2025-10-08T10:42:18	TJ: Guard against reused JPEG dst buf w/0 buf size The libjpeg in-memory destination manager has always re-allocated the JPEG destination buffer if the specified buffer pointer is NULL or the specified buffer size is 0. TurboJPEG's destination manager inherited that behavior. Because of fe80ec22752cce224c55d7b429d46503634ef034, TurboJPEG's destination manager tries to reuse the most recent destination buffer if the same buffer pointer is specified. (The purpose of that is to enable repeated invocations of tjCompress() or tjTransform() to automatically grow the destination buffer, as needed, with no intervention from the calling program.) However, because of the inherited code, TurboJPEG's destination manager also reallocated the destination buffer if the specified buffer size was 0. Thus, passing a previously-used JPEG destination buffer pointer to tjCompress() or tjTransform() while specifying a destination buffer size of 0 confused the destination manager. It reallocated the destination buffer to 4096 bytes but reported the old destination buffer size to the libjpeg API. This caused a buffer overrun if the old destination buffer size was larger than 4096 bytes. The documentation for tjCompress() is contradictory on this matter. It states that the JPEG destination buffer size must be specified if the destination buffer pointer is non-NULL. However, it also states that, if the destination buffer is reused, the specified destination buffer size is ignored. The documentation for tj*Transform() does not specify the function's behavior if the destination buffer is reused. Thus, the behavior of the API is at best undefined if a calling application attempts to reuse a destination buffer while specifying a destination buffer size of 0. If that ever worked, it only worked in libjpeg-turbo 1.3.x and prior. This issue was exposed only through API abuse, and calling applications that abused the API in that manner would not have worked for the last 11 years. Thus, the issue did not represent a security threat. This commit merely hardens the API against such abuse, by modifying TurboJPEG's destination manager so that it refuses to re-allocate the JPEG destination buffer if the buffer pointer is reused and the specified buffer size is 0. That is consistent with the most permissive interpretation of the TurboJPEG API documentation. (The API already ignored the destination buffer size if the destination buffer pointer was reused and the specified buffer size was non-zero. It makes sense for it to do likewise if the specified buffer size is 0.) This commit also modifies TJUnitTest so that it verifies whether the API is hardened against the aforementioned abuse.
e3e353fe	2024-09-06T20:30:03	tjunittest.c: Store/retrieve original buf size ... ... between iterations. (oversight from c519d7b67913e69b667f5fac49650f825e56218d)
6ec8e41f	2024-06-13T11:52:13	Handle lossless JPEG images w/2-15 bits per sample Closes #768 Closes #769
c8c5c2e5	2024-03-06T15:33:47	Merge branch 'main' into dev
e69dd40c	2024-01-23T13:26:41	Reorganize source to make things easier to find - Move all libjpeg documentation, except for README.ijg, into the doc/ subdirectory. - Move the TurboJPEG C API documentation from doc/html/ into doc/turbojpeg/. - Move all C source code and headers into a src/ subdirectory. - Move turbojpeg-jni.c into the java/ subdirectory. Referring to #226, there is no ideal solution to this problem. A semantically ideal solution would have involved placing all source code, including the SIMD and Java source code, under src/ (or perhaps placing C library source code under lib/ and C test program source code under test/), all header files under include/, and all documentation under doc/. However: - To me it makes more sense to have separate top-level directories for each language, since the SIMD extensions and the Java API are technically optional features. src/ now contains only the code that is relevant to the core C API libraries and associated programs. - I didn't want to bury the java/ and simd/ directories or add a level of depth to them, since both directories already contain source code that is 3-4 levels deep. - I would prefer not to separate the header files from the C source code, because: 1. It would be disruptive. libjpeg and libjpeg-turbo have historically placed C source code and headers in the same directory, and people who are familiar with both projects (self included) are used to looking for the headers in the same directory as the C source code. 2. In terms of how the headers are used internally in libjpeg-turbo, the distinction between public and private headers is a bit fuzzy. - It didn't make sense to separate the test source code from the library source code, since there is not a clear distinction in some cases. (For instance, the IJG image I/O functions are used by cjpeg and djpeg as well as by the TurboJPEG API.) This solution is minimally disruptive, since it keeps all C source code and headers together and keeps java/ and simd/ as top-level directories. It is a bit awkward, because java/ and simd/ technically contain source code, even though they are not under src/. However, other solutions would have been more awkward for different reasons. Closes #226

6d48aaac

2025-10-22T10:30:53

TJ: Handle lossless/CS params w/ YUV enc/compress - If TJPARAM_LOSSLESS was set, then tj3EncodeYUV*8() called jpeg_enable_lossless() (via setCompDefaults()), which caused the underlying libjpeg API to silently disable subsampling and color conversion. This led to three issues: 1. Attempting to encode RGB pixels produced incorrect YCbCr or grayscale components, since color conversion did not occur. The same issue occurred if TJPARAM_COLORSPACE was explicitly set to TJCS_RGB. 2. Attempting to encode RGB pixels into a grayscale plane caused tj3EncodeYUVPlanes8() to overflow the caller's destination pointer array if the array was not big enough to accommodate three pointers. If called from tj3EncodeYUV8(), tj3EncodeYUVPlanes8() did not overflow the caller's destination pointer array, but a segfault occurred when it attempted to copy to the Cb and Cr pointers, which were NULL. The same issue occurred if TJPARAM_COLORSPACE was explicitly set to anything other than TJCS_GRAY. 3. Attempting to encode RGB pixels into subsampled YUV planes caused tj3EncodeYUV*8() to overflow the caller's buffer(s) if the buffer(s) were not big enough to accommodate 4:4:4 (non-subsampled) YUV planes. That would have been the case if the caller allocated its buffer(s) based on the return value of tj3YUVBufSize() or tj3YUVPlaneSize(). The same issue occurs if TJPARAM_SUBSAMP is explicitly set to TJSAMP_444. tj3EncodeYUV*8() now ignores TJPARAM_LOSSLESS and TJPARAM_COLORSPACE. - If TJPARAM_LOSSLESS was set, then attempting to compress a grayscale plane into a JPEG image caused tj3CompressFromYUVPlanes8() to overflow the caller's source pointer array if the array was not big enough to accommodate three pointers. If called from tj3CompressFromYUV8(), tj3CompressFromYUVPlanes8() did not overflow the caller's source pointer array, but a segfault occurred when it attempted to copy from the Cb and Cr pointers, which were NULL. This was similar to Issue 2 above. The same issue occurred if TJPARAM_COLORSPACE was explicitly set to anything other than TJCS_GRAY. tj3CompressFromYUV*8() now throws an error if TJPARAM_LOSSLESS is set, and it now ignores TJPARAM_COLORSPACE. These issues did not pose a security risk, since security exploits involve supported workflows that function normally except when supplied with malformed input data. It is documented that colorspace conversion, chrominance subsampling, and compression from planar YUV images are unavailable when TJPARAM_LOSSLESS is set. When TJPARAM_LOSSLESS is set, the library effectively sets TJPARAM_SUBSAMP to TJSAMP_444 and TJPARAM_COLORSPACE to TJCS_RGB, TJCS_GRAY, or TJCS_CMYK, depending on the pixel format of the source image. That behavior is strongly implied by the documentation of TJPARAM_LOSSLESS, although the documentation isn't specific about whether TJPARAM_LOSSLESS applies to tj3EncodeYUV*8(). In any case, setting TJPARAM_LOSSLESS before calling tj3CompressFromYUV*8() was never a supported or functional workflow, and setting TJPARAM_LOSSLESS before calling tj3EncodeYUV*8() was never a functional workflow. Thus, there should be no applications "in the wild" that use either workflow. Such applications would crash every time they attempted to encode to or compress from a YUV image. In other words, setting TJPARAM_LOSSLESS or TJPARAM_COLORSPACE required the caller to understand the ramifications of the loss of color conversion and/or subsampling, and failing to do so was essentially API abuse (albeit subtle API abuse, hence the desire to make the behavior more intuitive.) This commit also removes no-op code introduced by 6da05150efa9b7a190d05bf82295127c778d15ab. Since setCompDefaults() returns after calling jpeg_enable_lossless(), modifying the subsampling level locally had no effect. The libjpeg API already silently disables subsampling in jinit_c_master_control() if lossless compression is enabled, so it was not necessary for setCompDefaults() to handle that. Fixes #839

1f3614f1

2025-10-08T10:42:18

TJ: Guard against reused JPEG dst buf w/0 buf size The libjpeg in-memory destination manager has always re-allocated the JPEG destination buffer if the specified buffer pointer is NULL or the specified buffer size is 0. TurboJPEG's destination manager inherited that behavior. Because of fe80ec22752cce224c55d7b429d46503634ef034, TurboJPEG's destination manager tries to reuse the most recent destination buffer if the same buffer pointer is specified. (The purpose of that is to enable repeated invocations of tj*Compress*() or tj*Transform() to automatically grow the destination buffer, as needed, with no intervention from the calling program.) However, because of the inherited code, TurboJPEG's destination manager also reallocated the destination buffer if the specified buffer size was 0. Thus, passing a previously-used JPEG destination buffer pointer to tj*Compress*() or tj*Transform() while specifying a destination buffer size of 0 confused the destination manager. It reallocated the destination buffer to 4096 bytes but reported the old destination buffer size to the libjpeg API. This caused a buffer overrun if the old destination buffer size was larger than 4096 bytes. The documentation for tj*Compress*() is contradictory on this matter. It states that the JPEG destination buffer size must be specified if the destination buffer pointer is non-NULL. However, it also states that, if the destination buffer is reused, the specified destination buffer size is ignored. The documentation for tj*Transform() does not specify the function's behavior if the destination buffer is reused. Thus, the behavior of the API is at best undefined if a calling application attempts to reuse a destination buffer while specifying a destination buffer size of 0. If that ever worked, it only worked in libjpeg-turbo 1.3.x and prior. This issue was exposed only through API abuse, and calling applications that abused the API in that manner would not have worked for the last 11 years. Thus, the issue did not represent a security threat. This commit merely hardens the API against such abuse, by modifying TurboJPEG's destination manager so that it refuses to re-allocate the JPEG destination buffer if the buffer pointer is reused and the specified buffer size is 0. That is consistent with the most permissive interpretation of the TurboJPEG API documentation. (The API already ignored the destination buffer size if the destination buffer pointer was reused and the specified buffer size was non-zero. It makes sense for it to do likewise if the specified buffer size is 0.) This commit also modifies TJUnitTest so that it verifies whether the API is hardened against the aforementioned abuse.

e3e353fe

2024-09-06T20:30:03

tjunittest.c: Store/retrieve original buf size ... ... between iterations. (oversight from c519d7b67913e69b667f5fac49650f825e56218d)

6ec8e41f

2024-06-13T11:52:13

Handle lossless JPEG images w/2-15 bits per sample Closes #768 Closes #769

c8c5c2e5

2024-03-06T15:33:47

Merge branch 'main' into dev

e69dd40c

2024-01-23T13:26:41

Reorganize source to make things easier to find - Move all libjpeg documentation, except for README.ijg, into the doc/ subdirectory. - Move the TurboJPEG C API documentation from doc/html/ into doc/turbojpeg/. - Move all C source code and headers into a src/ subdirectory. - Move turbojpeg-jni.c into the java/ subdirectory. Referring to #226, there is no ideal solution to this problem. A semantically ideal solution would have involved placing all source code, including the SIMD and Java source code, under src/ (or perhaps placing C library source code under lib/ and C test program source code under test/), all header files under include/, and all documentation under doc/. However: - To me it makes more sense to have separate top-level directories for each language, since the SIMD extensions and the Java API are technically optional features. src/ now contains only the code that is relevant to the core C API libraries and associated programs. - I didn't want to bury the java/ and simd/ directories or add a level of depth to them, since both directories already contain source code that is 3-4 levels deep. - I would prefer not to separate the header files from the C source code, because: 1. It would be disruptive. libjpeg and libjpeg-turbo have historically placed C source code and headers in the same directory, and people who are familiar with both projects (self included) are used to looking for the headers in the same directory as the C source code. 2. In terms of how the headers are used internally in libjpeg-turbo, the distinction between public and private headers is a bit fuzzy. - It didn't make sense to separate the test source code from the library source code, since there is not a clear distinction in some cases. (For instance, the IJG image I/O functions are used by cjpeg and djpeg as well as by the TurboJPEG API.) This solution is minimally disruptive, since it keeps all C source code and headers together and keeps java/ and simd/ as top-level directories. It is a bit awkward, because java/ and simd/ technically contain source code, even though they are not under src/. However, other solutions would have been more awkward for different reasons. Closes #226

kc3-lang/libjpeg-turbo/src/tjunittest.c

src/tjunittest.c

Log