From $URL: [258723] Medium CVE-2013-6629: Read of uninitialized memory in libjpeg and libjpeg-turbo. Credit to Michal Zalewski of Google.
The commit from the chromium repo, not applied to upstream: http://src.chromium.org/viewvc/chrome/trunk/src/third_party/libjpeg/jdmarker.c?r1=228354&r2=228353&pathrev=228354
=media-libs/jpeg-6b is vulnerable, and all versions in the 62 slot are 6b versions. icedtea-bin, and possibly other packages, depends on the 62 slot.
(In reply to Agostino Sarubbo from comment #1) > The commit from the chromium repo, not applied to upstream: > > http://src.chromium.org/viewvc/chrome/trunk/src/third_party/libjpeg/jdmarker. > c?r1=228354&r2=228353&pathrev=228354 The CVE is vague on specific version scale for jpeg...? The patch applies to jpeg-8d, is fixed at jpeg-8d-r1 in Portage now The patch applies to jpeg-9-r1, is not fixed because it causes a build failure Was this already fixed differently for jpeg-9 at upstream?
The patch that went into media-libs/libjpeg-turbo also fixed CVE-2013-6630. Is that not valid for media-libs/jpeg?
(In reply to Samuli Suominen from comment #4) > The patch that went into media-libs/libjpeg-turbo also fixed CVE-2013-6630. > Is that not valid for media-libs/jpeg? http://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/media-libs/libjpeg-turbo/files/libjpeg-turbo-1.3.0-CVE-2013-6629-and-6630.patch?view=log
I'm going to handle stabilization in bug 491150 and leave this bug open because there remain unanswered questions. I've package.masked >=media-libs/jpeg-9 in tree pending both, on the bugs in Tracker bug 479818 and the resolution of this bug. - Does jpeg-6b, 8d, 9 need a patch for CVE-2013-6630? - Does jpeg-9 need a patch for this bug? The one mentioned here causes build failure.
jpeg-9a was released and is in Portage without any patches. this still apply?
@ Maintainer(s): =media-libs/jpeg-6b-r12: Safe, applies jpeg-8d-CVE-2013-6629.patch =media-libs/jpeg-8d-r1 and =media-libs/jpeg-8d-r2: Safe, applies jpeg-8d-CVE-2013-6629.patch =media-libs/jpeg-9a and =media-libs/jpeg-9b are both *vulnerable*. Please tell us if you are going to apply the patch to v9 as well or what action you are going to take.
(In reply to Thomas Deutschmann from comment #8) > @ Maintainer(s): > > =media-libs/jpeg-6b-r12: Safe, applies jpeg-8d-CVE-2013-6629.patch > > =media-libs/jpeg-8d-r1 and =media-libs/jpeg-8d-r2: Safe, applies > jpeg-8d-CVE-2013-6629.patch > > =media-libs/jpeg-9a and =media-libs/jpeg-9b are both *vulnerable*. Please > tell us if you are going to apply the patch to v9 as well or what action you > are going to take. @maintainer(s), ping.
Summary: The get_sos function in jdmarker.c in (1) libjpeg 6b and (2) libjpeg-turbo through 1.3.0, as used in Google Chrome before 31.0.1650.48, Ghostscript, and other products, does not check for certain duplications of component data during the reading of segments that follow Start Of Scan (SOS) JPEG markers, which allows remote attackers to obtain sensitive information from uninitialized memory locations via a crafted JPEG image. Published: 2013-11-19T04:50:56.000Z
(In reply to Aaron Bauman from comment #9) > (In reply to Thomas Deutschmann from comment #8) > > @ Maintainer(s): > > > > =media-libs/jpeg-6b-r12: Safe, applies jpeg-8d-CVE-2013-6629.patch > > > > =media-libs/jpeg-8d-r1 and =media-libs/jpeg-8d-r2: Safe, applies > > jpeg-8d-CVE-2013-6629.patch > > > > =media-libs/jpeg-9a and =media-libs/jpeg-9b are both *vulnerable*. Please > > tell us if you are going to apply the patch to v9 as well or what action you > > are going to take. > > @maintainer(s), ping. The same fixes are included in the jpeg9c source. The code layout is slightly different as the code base has grown, but the same protections are in place. All sources in the tree are now patched.
After further review of the CVE's this is being downgraded to an A4. As such, we will not release a GLSA. GLSA Vote: No.
