A Heap-based buffer overflow was found in the way libjpeg-turbo decompressed certain corrupt JPEG images in which the component count was erroneously set to a large value. An attacker could create a specially-crafted JPEG image that, when opened, could cause an application using libpng to crash or, possibly, execute arbitrary code with the privileges of the user running the application.

Patch: http://libjpeg-turbo.svn.sourceforge.net/viewvc/libjpeg-turbo?view=revision&revision=830

References: http://code.google.com/p/chromium/issues/detail?id=130240 https://bugzilla.mozilla.org/showbug.cgi?id=759802

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.

References: https://github.com/libjpeg-turbo/libjpeg-turbo/issues/493 [https://github.com/libjpeg-turbo/libjpeg-turbo/issues/493 https://github.com/libjpeg-turbo/libjpeg-turbo/commit/1719d12e51641cce5c77e259516649ba5ef6303c

DISPUTED In libjpeg-turbo 2.0.2, a large amount of memory can be used during processing of an invalid progressive JPEG image containing incorrect width and height values in the image header. NOTE: the vendor's expectation, for use cases in which this memory usage would be a denial of service, is that the application should interpret libjpeg warnings as fatal errors (aborting decompression) and/or set limits on resource consumption or image sizes.

get8bitrow in rdbmp.c in libjpeg-turbo through 1.5.90 and MozJPEG through 3.3.1 allows attackers to cause a denial of service (heap-based buffer over-read and application crash) via a crafted 8-bit BMP in which one or more of the color indices is out of range for the number of palette entries.

Upstream patch: https://github.com/libjpeg-turbo/libjpeg-turbo/commit/9c78a04df4e44ef6487eee99c4258397f4fdca55

Upstream issue: https://github.com/libjpeg-turbo/libjpeg-turbo/issues/258

References: https://github.com/mozilla/mozjpeg/issues/299