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.)
This commit is contained in:
DRC
2016-04-21 10:22:36 -05:00
parent dec79952d6
commit 1959e28b49

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
header using the `tjDecompressToYUV2()` function would cause the function to
abort without returning an error. This only occurred if `tjDecompressToYUV2()`
was called prior to calling `tjDecompressHeader3()`, or if the return value
from `tjDecompressHeader3()` was ignored (both cases represent incorrect usage
of the TurboJPEG API.)
abort without returning an error and, under certain circumstances, corrupt the
stack. This only occurred if `tjDecompressToYUV2()` was called prior to
calling `tjDecompressHeader3()`, or if the return value from
`tjDecompressHeader3()` was ignored (both cases represent incorrect usage of
the TurboJPEG API.)
1.4.90 (1.5 beta1)