pool/libjpeg-turbo
SHA256
4
0
Fork 1
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Accepting request 789475 from home:ukbeast89:branches:graphics

Browse Source 
- Upate to version 2.0.4:
- bug 388 was fixed upstream
  https://github.com/libjpeg-turbo/libjpeg-turbo/issues/388
- removed patches, as it is included in this release.
  * Fixed a regression in the Windows packaging system 
   (introduced by 2.0 beta1[2]) whereby, if both the 64-bit libjpeg-turbo 
   SDK for GCC and the 64-bit libjpeg-turbo SDK for Visual C++ were installed 
   on the same system, only one of them could be uninstalled.
  * Fixed a signed integer overflow and subsequent segfault that occurred when 
    attempting to decompress images with more than 715827882 pixels using the 64-bit C version of TJBench.
  * Fixed out-of-bounds write in tjDecompressToYUV2() and tjDecompressToYUVPlanes() 
    (sometimes manifesting as a double free) that occurred when attempting to decompress 
    grayscale JPEG images that were compressed with a sampling factor other than 1 
    (for instance, with cjpeg -grayscale -sample 2x2).
  * Fixed a regression introduced by 2.0.2[5] that caused the TurboJPEG API to incorrectly 
    identify some JPEG images with unusual sampling factors as 4:4:4 JPEG images. 
    This was known to cause a buffer overflow when attempting to decompress some such images using 
    tjDecompressToYUV2() or tjDecompressToYUVPlanes().
  * Fixed an issue, detected by ASan, whereby attempting to losslessly transform a specially-crafted 
    malformed JPEG image containing an extremely-high-frequency coefficient block 
    (junk image data that could never be generated by a legitimate JPEG compressor) could cause the 
    Huffman encoder's local buffer to be overrun. (Refer to 1.4.0[9] and 1.4beta1[15].) 
    Given that the buffer overrun was fully contained within the stack and did not cause a segfault 
    or other user-visible errant behavior, and given that the lossless transformer (unlike the decompressor) 
    is not generally exposed to arbitrary data exploits, this issue did not likely pose a security risk.
    The ARM 64-bit (ARMv8) NEON SIMD assembly code now stores constants in a separate read-only data 
    section rather than in the text section, to support execute-only memory layouts.
- Upate to version 2.0.4:
  * Fixed a regression in the Windows packaging system 
   (introduced by 2.0 beta1[2]) whereby, if both the 64-bit libjpeg-turbo 
   SDK for GCC and the 64-bit libjpeg-turbo SDK for Visual C++ were installed 
   on the same system, only one of them could be uninstalled.
  * Fixed a signed integer overflow and subsequent segfault that occurred when 
    attempting to decompress images with more than 715827882 pixels using the 64-bit C version of TJBench.
  * Fixed out-of-bounds write in tjDecompressToYUV2() and tjDecompressToYUVPlanes() 
    (sometimes manifesting as a double free) that occurred when attempting to decompress 
    grayscale JPEG images that were compressed with a sampling factor other than 1 
    (for instance, with cjpeg -grayscale -sample 2x2).
  * Fixed a regression introduced by 2.0.2[5] that caused the TurboJPEG API to incorrectly 
    identify some JPEG images with unusual sampling factors as 4:4:4 JPEG images. 
    This was known to cause a buffer overflow when attempting to decompress some such images using 
    tjDecompressToYUV2() or tjDecompressToYUVPlanes().
  * Fixed an issue, detected by ASan, whereby attempting to losslessly transform a specially-crafted 
    malformed JPEG image containing an extremely-high-frequency coefficient block 
    (junk image data that could never be generated by a legitimate JPEG compressor) could cause the 
    Huffman encoder's local buffer to be overrun. (Refer to 1.4.0[9] and 1.4beta1[15].) 
    Given that the buffer overrun was fully contained within the stack and did not cause a segfault 
    or other user-visible errant behavior, and given that the lossless transformer (unlike the decompressor) 
    is not generally exposed to arbitrary data exploits, this issue did not likely pose a security risk.
    The ARM 64-bit (ARMv8) NEON SIMD assembly code now stores constants in a separate read-only data 
    section rather than in the text section, to support execute-only memory layouts.

OBS-URL: https://build.opensuse.org/request/show/789475
OBS-URL: https://build.opensuse.org/package/show/graphics/libjpeg-turbo?expand=0&rev=104
This commit is contained in:
Petr Gajdos 2020-03-30 07:51:51 +00:00 committed by Git OBS Bridge
parent 551c77d69b
commit 6c22e4b5a5
9 changed files with 65 additions and 29 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

3
libjpeg-turbo-2.0.3.tar.gz
View File

@ -1,3 +0,0 @@
version https://git-lfs.github.com/spec/v1
oid sha256:4246de500544d4ee408ee57048aa4aadc6f165fc17f141da87669f20ed3241b7
size 2161279

BIN
libjpeg-turbo-2.0.3.tar.gz.sig
View File

Binary file not shown.

3
libjpeg-turbo-2.0.4.tar.gz Normal file
View File

@ -0,0 +1,3 @@
version https://git-lfs.github.com/spec/v1
oid sha256:7777c3c19762940cff42b3ba4d7cd5c52d1671b39a79532050c85efb99079064
size 2161812

BIN
libjpeg-turbo-2.0.4.tar.gz.sig Normal file
View File

Binary file not shown.

21
libjpeg-turbo-issue-388.patch
View File

@ -1,21 +0,0 @@
--- a/tjbench.c
+++ b/tjbench.c
@@ -171,7 +171,7 @@ static int decomp(unsigned char *srcBuf, unsigned char **jpegBuf,
}
/* Set the destination buffer to gray so we know whether the decompressor
attempted to write to it */
- memset(dstBuf, 127, pitch * scaledh);
+ memset(dstBuf, 127, (size_t)pitch * scaledh);
if (doYUV) {
int width = doTile ? tilew : scaledw;
@@ -193,7 +193,7 @@ static int decomp(unsigned char *srcBuf, unsigned char **jpegBuf,
double start = getTime();
for (row = 0, dstPtr = dstBuf; row < ntilesh;
- row++, dstPtr += pitch * tileh) {
+ row++, dstPtr += (size_t)pitch * tileh) {
for (col = 0, dstPtr2 = dstPtr; col < ntilesw;
col++, tile++, dstPtr2 += ps * tilew) {
int width = doTile ? min(tilew, w - col * tilew) : scaledw;

32
libjpeg-turbo.changes
View File

@ -1,3 +1,35 @@
-------------------------------------------------------------------
Sun Mar 29 10:02:02 UTC 2020 - Aaron Stern <ukbeast89@protonmail.com>
- Upate to version 2.0.4:
- bug 388 was fixed upstream
https://github.com/libjpeg-turbo/libjpeg-turbo/issues/388
- removed patches, as it is included in this release.
* Fixed a regression in the Windows packaging system
(introduced by 2.0 beta1[2]) whereby, if both the 64-bit libjpeg-turbo
SDK for GCC and the 64-bit libjpeg-turbo SDK for Visual C++ were installed
on the same system, only one of them could be uninstalled.
* Fixed a signed integer overflow and subsequent segfault that occurred when
attempting to decompress images with more than 715827882 pixels using the 64-bit C version of TJBench.
* Fixed out-of-bounds write in tjDecompressToYUV2() and tjDecompressToYUVPlanes()
(sometimes manifesting as a double free) that occurred when attempting to decompress
grayscale JPEG images that were compressed with a sampling factor other than 1
(for instance, with cjpeg -grayscale -sample 2x2).
* Fixed a regression introduced by 2.0.2[5] that caused the TurboJPEG API to incorrectly
identify some JPEG images with unusual sampling factors as 4:4:4 JPEG images.
This was known to cause a buffer overflow when attempting to decompress some such images using
tjDecompressToYUV2() or tjDecompressToYUVPlanes().
* Fixed an issue, detected by ASan, whereby attempting to losslessly transform a specially-crafted
malformed JPEG image containing an extremely-high-frequency coefficient block
(junk image data that could never be generated by a legitimate JPEG compressor) could cause the
Huffman encoder's local buffer to be overrun. (Refer to 1.4.0[9] and 1.4beta1[15].)
Given that the buffer overrun was fully contained within the stack and did not cause a segfault
or other user-visible errant behavior, and given that the lossless transformer (unlike the decompressor)
is not generally exposed to arbitrary data exploits, this issue did not likely pose a security risk.
The ARM 64-bit (ARMv8) NEON SIMD assembly code now stores constants in a separate read-only data
section rather than in the text section, to support execute-only memory layouts.
-------------------------------------------------------------------
Tue Mar 17 05:52:14 UTC 2020 - John Whately <john+OpenSuse@whately.me>

5
libjpeg-turbo.spec
View File

@ -19,7 +19,7 @@
%define asan_build 0
%define debug_build 0
%define srcver 2.0.3
%define srcver 2.0.4
%define major 8
%define minor 2
%define micro 2
@ -39,8 +39,6 @@ Source0: http://downloads.sf.net/libjpeg-turbo/libjpeg-turbo-%{version}.t
Source1: baselibs.conf
Patch1: libjpeg-turbo-1.3.0-tiff-ojpeg.patch
Patch2: ctest-depends.patch
# https://github.com/libjpeg-turbo/libjpeg-turbo/issues/388
Patch3: libjpeg-turbo-issue-388.patch
BuildRequires: cmake
BuildRequires: gcc-c++
BuildRequires: pkgconfig
@ -106,7 +104,6 @@ files using the libjpeg library.
%setup -q
%patch1
%patch2 -p1
%patch3 -p1
%build
MYLDFLAGS="-Wl,-z,relro,-z,now"

28
libjpeg62-turbo.changes
View File

@ -1,3 +1,31 @@
-------------------------------------------------------------------
Sun Mar 29 10:17:03 UTC 2020 - Aaron Stern <ukbeast89@protonmail.com>
- Upate to version 2.0.4:
* Fixed a regression in the Windows packaging system
(introduced by 2.0 beta1[2]) whereby, if both the 64-bit libjpeg-turbo
SDK for GCC and the 64-bit libjpeg-turbo SDK for Visual C++ were installed
on the same system, only one of them could be uninstalled.
* Fixed a signed integer overflow and subsequent segfault that occurred when
attempting to decompress images with more than 715827882 pixels using the 64-bit C version of TJBench.
* Fixed out-of-bounds write in tjDecompressToYUV2() and tjDecompressToYUVPlanes()
(sometimes manifesting as a double free) that occurred when attempting to decompress
grayscale JPEG images that were compressed with a sampling factor other than 1
(for instance, with cjpeg -grayscale -sample 2x2).
* Fixed a regression introduced by 2.0.2[5] that caused the TurboJPEG API to incorrectly
identify some JPEG images with unusual sampling factors as 4:4:4 JPEG images.
This was known to cause a buffer overflow when attempting to decompress some such images using
tjDecompressToYUV2() or tjDecompressToYUVPlanes().
* Fixed an issue, detected by ASan, whereby attempting to losslessly transform a specially-crafted
malformed JPEG image containing an extremely-high-frequency coefficient block
(junk image data that could never be generated by a legitimate JPEG compressor) could cause the
Huffman encoder's local buffer to be overrun. (Refer to 1.4.0[9] and 1.4beta1[15].)
Given that the buffer overrun was fully contained within the stack and did not cause a segfault
or other user-visible errant behavior, and given that the lossless transformer (unlike the decompressor)
is not generally exposed to arbitrary data exploits, this issue did not likely pose a security risk.
The ARM 64-bit (ARMv8) NEON SIMD assembly code now stores constants in a separate read-only data
section rather than in the text section, to support execute-only memory layouts.
-------------------------------------------------------------------
Tue Mar 17 05:52:14 UTC 2020 - John Whately <john+OpenSuse@whately.me>

2
libjpeg62-turbo.spec
View File

@ -19,7 +19,7 @@
%define major 62
%define minor 3
%define micro 0
%define srcver 2.0.3
%define srcver 2.0.4
%define libver %{major}.%{minor}.%{micro}
Name: libjpeg62-turbo
Version: %{srcver}