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.)

diff --git a/ChangeLog.md b/ChangeLog.md
index 7e40f76fc84e362fea6e502cff26bef2f4fb452c..99ab595603b5dc32ff99f0a5ffc17fbe9cfd1307 100644 (file)
--- a/ChangeLog.md
+++ b/ChangeLog.md
@@ -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)