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. References: https://bugzilla.redhat.com/show_bug.cgi?id=826849 http://libjpeg-turbo.svn.sourceforge.net/viewvc/libjpeg-turbo?view=revision&revision=830 This issue has been assigned CVE-2012-2806. Upstream release of libjpeg-turbo-1.2.1 resolves this issue. Reproducible: Always
Test and stabilize: =media-libs/libjpeg-turbo-1.2.1 alpha amd64 arm hppa ia64 m68k ppc ppc64 s390 sh sparc x86
btw, this is the same fix that Samuli added to libjpeg-turbo-1.2.0-r2
x86 stable
Stable for HPPA.
amd64 done
alpha/arm/ia64/m68k/s390/sh/sparc stable
ppc/ppc64 done all arch's done
Thanks, everyone. GLSA draft ready for review.
CVE-2012-2806 (http://nvd.nist.gov/nvd.cfm?cvename=CVE-2012-2806): Heap-based buffer overflow in the get_sos function in jdmarker.c in libjpeg-turbo 1.2.0 allows remote attackers to cause a denial of service (application crash) and possibly execute arbitrary code via a large component count in the header of a JPEG image.
This issue was resolved and addressed in GLSA 201209-13 at http://security.gentoo.org/glsa/glsa-201209-13.xml by GLSA coordinator Sean Amoss (ackle).