ryan/mozjpeg
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Increase severity of tjDecompressToYUV2() bug desc

Browse Source 
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.)
This commit is contained in:
DRC
2016-04-21 10:22:36 -05:00
parent dec79952d6
commit 1959e28b49
1 changed files with 5 additions and 4 deletions
Download Patch File Download Diff File Expand all files Collapse all files

9
ChangeLog.md
View File

@@ -21,10 +21,11 @@ affect any of the libjpeg-turbo libraries.
4. Fixed an issue whereby attempting to decompress a JPEG file with a corrupt 4. Fixed an issue whereby attempting to decompress a JPEG file with a corrupt
header using the `tjDecompressToYUV2()` function would cause the function to header using the `tjDecompressToYUV2()` function would cause the function to
abort without returning an error. This only occurred if `tjDecompressToYUV2()` abort without returning an error and, under certain circumstances, corrupt the
was called prior to calling `tjDecompressHeader3()`, or if the return value stack. This only occurred if `tjDecompressToYUV2()` was called prior to
from `tjDecompressHeader3()` was ignored (both cases represent incorrect usage calling `tjDecompressHeader3()`, or if the return value from
of the TurboJPEG API.) `tjDecompressHeader3()` was ignored (both cases represent incorrect usage of
the TurboJPEG API.)
1.4.90 (1.5 beta1) 1.4.90 (1.5 beta1)