Libjpeg-turbo (versions 2.0.91 and 2.0.90) is vulnerable to a denial of service vulnerability caused by a divide by zero when processing a crafted GIF image.
Created libjpeg-turbo tracking bugs for this issue:
Affects: fedora-all [bug 1937387]
Created mingw-libjpeg-turbo tracking bugs for this issue:
Affects: fedora-all [bug 1937388]
Denial of service? Really? What, pray tell, is the "service" that was being denied? This bug was confined to the cjpeg application, whose main purpose is to demonstrate the usage of the libjpeg API library. The library itself was not affected, and thus no other applications were affected. Assigning a CVE to this seems like an overreaction, particularly given that the bug was a regression introduced by a new feature in a beta (non-production) release of libjpeg-turbo, and the bug was fixed two months before this Bugzilla issue was even created. To those in the open source community, please stop abusing the term "DoS". cjpeg is not, by any stretch of the imagination, a "service", and if it crashes rather than bowing out gracefully on a corrupt input image, that isn't a "denial of service."
This flaw does not affect versions of libjpeg-turbo shipped with Red Hat Enterprise Linux versions 6, 7, or 8. Additionally, it is not in the library, only the cjpeg utility.
Correct. More specifically, the flaw only affects libjpeg-turbo 2.1 beta1. It was introduced as part of a new feature in libjpeg-turbo 2.1 that adds support for creating JPEG files from LZW-compressed GIF files using cjpeg.
Also please note that 2.0.91 is not an official release of libjpeg-turbo. 2.0.90 is 2.1 beta1. The version number in the Git repository was bumped to 2.0.91 for post-beta commits, but that version number would only become official if it were necessary to put out a beta2 release (which it isn't.) Thus, to be 100% correct, this issue affects:
- The official 2.0.90 (2.1 beta1) release
- Any unofficial/pre-release builds with a version number of 2.0.91 and a build number < 20210114