From 1959e28b495003fd43e343b9de14426a9b2b4cab Mon Sep 17 00:00:00 2001 From: DRC Date: Thu, 21 Apr 2016 10:22:36 -0500 Subject: [PATCH] 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.) --- ChangeLog.md | 9 +++++---- 1 file changed, 5 insertions(+), 4 deletions(-) diff --git a/ChangeLog.md b/ChangeLog.md index 7e40f76f..99ab5956 100644 --- 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)