| Summary: | <media-libs/libjpeg-turbo-1.5.0: Out-of-Bounds Read via unusually long Blocks in MCU | ||
|---|---|---|---|
| Product: | Gentoo Security | Reporter: | Agostino Sarubbo <ago> |
| Component: | Vulnerabilities | Assignee: | Gentoo Security <security> |
| Status: | RESOLVED FIXED | ||
| Severity: | major | ||
| Priority: | Normal | ||
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | Linux | ||
| URL: | https://bugzilla.redhat.com/show_bug.cgi?id=1344732 | ||
| Whiteboard: | A2 [glsa] | ||
| Package list: | Runtime testing required: | --- | |
| Bug Depends on: | 586192, 586336 | ||
| Bug Blocks: | |||
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 Stable on alpha. Stable for PPC64. Stable for HPPA. arm stable amd64 stable x86 stable ppc stable sparc stable ia64 stable. Maintainer(s), please cleanup. (In reply to Agostino Sarubbo from comment #6) > amd64 stable Why are you stabilizing without taking care of the blocker stabilization (bug #586192)? (In reply to Agostino Sarubbo from comment #10) > Maintainer(s), please cleanup. done. GLSA request filed. This issue was resolved and addressed in GLSA 201612-55 at https://security.gentoo.org/glsa/201612-55 by GLSA coordinator Thomas Deutschmann (whissi). |
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.