Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 585782 - <media-libs/libjpeg-turbo-1.5.0: Out-of-Bounds Read via unusually long Blocks in MCU
Summary: <media-libs/libjpeg-turbo-1.5.0: Out-of-Bounds Read via unusually long Blocks...
Status: RESOLVED FIXED
Alias: None
Product: Gentoo Security
Classification: Unclassified
Component: Vulnerabilities (show other bugs)
Hardware: All Linux
: Normal major (vote)
Assignee: Gentoo Security
URL: https://bugzilla.redhat.com/show_bug....
Whiteboard: A2 [glsa]
Keywords:
Depends on: 586192 586336
Blocks:
  Show dependency tree
 
Reported: 2016-06-13 07:34 UTC by Agostino Sarubbo
Modified: 2016-12-31 15:43 UTC (History)
0 users

See Also:
Package list:
Runtime testing required: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Agostino Sarubbo gentoo-dev 2016-06-13 07:34:53 UTC
From ${URL} :

A  performance optimization for simple and common cases entails that decode_mcu() calls 
decode_mcu_fast() to decode a single MCU. A greater speed of the latter function is attributed to 
the fact that it makes some assumptions that the slower decoding function is not allowed to make. 
One of these assumptions is that enough data is available in the input buffer, so 
decode_mcu_fast() does not perform bounds’ checks when reading from the input buffer (via 
GET_BYTE). Instead, decode_mcu() is responsible for ensuring that the input buffer is big enough 
for the worst case scenario.

However, the problem is that the estimate does not actually cover the worst case possibility. In 
specifics, the decode_mcu() assumes a maximum of 128 bytes per block while, actually, blocks with 
around 438 bytes in length can be crafted. (Note that these 438 bytes are not a proper worst-case 
estimate but rather just the length the PoC generates.)

External references:

https://wiki.mozilla.org/images/7/77/Libjpeg-turbo-report.pdf

Upstream fix:

https://github.com/libjpeg-turbo/libjpeg-turbo/commit/0463f7c9aad060fcd56e98d025ce16185279e2bc


@maintainer(s): after the bump, in case we need to stabilize the package, please let us know if it is ready for the stabilization or not.
Comment 1 Lars Wendler (Polynomial-C) (RETIRED) gentoo-dev 2016-06-14 10:07:54 UTC
commit 12d3189bd340784fe09717ab8ccc5acf9744f21a
Author: Lars Wendler <polynomial-c@gentoo.org>
Date:   Tue Jun 14 12:05:55 2016

    media-libs/libjpeg-turbo: Security bump (bug #585782).
    
    Package-Manager: portage-2.2.28
    Signed-off-by: Lars Wendler <polynomial-c@gentoo.org>


Arches please test and mark stable =media-libs/libjpeg-turbo-1.5.0 with target KEYWORDS:

alpha amd64 arm arm64 hppa ia64 ~m68k ~mips ppc ppc64 ~s390 ~sh sparc x86 ~amd64-fbsd ~x86-fbsd ~amd64-linux ~arm-linux ~x86-linux ~x64-macos ~x86-macos
Comment 2 Tobias Klausmann (RETIRED) gentoo-dev 2016-06-15 07:42:50 UTC
Stable on alpha.
Comment 3 Jeroen Roovers (RETIRED) gentoo-dev 2016-06-15 15:38:26 UTC
Stable for PPC64.
Comment 4 Jeroen Roovers (RETIRED) gentoo-dev 2016-06-21 11:33:15 UTC
Stable for HPPA.
Comment 5 Markus Meier gentoo-dev 2016-06-21 18:31:17 UTC
arm stable
Comment 6 Agostino Sarubbo gentoo-dev 2016-06-27 08:24:13 UTC
amd64 stable
Comment 7 Agostino Sarubbo gentoo-dev 2016-06-27 08:51:24 UTC
x86 stable
Comment 8 Agostino Sarubbo gentoo-dev 2016-07-08 07:59:36 UTC
ppc stable
Comment 9 Agostino Sarubbo gentoo-dev 2016-07-08 10:08:07 UTC
sparc stable
Comment 10 Agostino Sarubbo gentoo-dev 2016-07-08 12:07:19 UTC
ia64 stable.

Maintainer(s), please cleanup.
Comment 11 Alexandre Rostovtsev (RETIRED) gentoo-dev 2016-07-08 21:39:39 UTC
(In reply to Agostino Sarubbo from comment #6)
> amd64 stable

Why are you stabilizing without taking care of the blocker stabilization (bug #586192)?
Comment 12 Markus Meier gentoo-dev 2016-07-10 09:09:03 UTC
(In reply to Agostino Sarubbo from comment #10)
> Maintainer(s), please cleanup.

done.
Comment 13 Aaron Bauman (RETIRED) gentoo-dev 2016-11-20 06:29:33 UTC
GLSA request filed.
Comment 14 GLSAMaker/CVETool Bot gentoo-dev 2016-12-31 15:43:31 UTC
This issue was resolved and addressed in
 GLSA 201612-55 at https://security.gentoo.org/glsa/201612-55
by GLSA coordinator Thomas Deutschmann (whissi).