| Summary: | libjpeg 2.0.4 fixes security issues | ||
|---|---|---|---|
| Product: | Mageia | Reporter: | David Walser <luigiwalser> |
| Component: | Security | Assignee: | QA Team <qa-bugs> |
| Status: | RESOLVED FIXED | QA Contact: | Sec team <security> |
| Severity: | normal | ||
| Priority: | Normal | CC: | andrewsfarm, geiger.david68210, herman.viaene, nicolas.salguero, sysadmin-bugs, tmb |
| Version: | 7 | Keywords: | advisory, validated_update |
| Target Milestone: | --- | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | MGA7-64-OK | ||
| Source RPM: | libjpeg-2.0.3-1.mga7.src.rpm | CVE: | |
| Status comment: | |||
|
Description
David Walser
2020-01-12 17:28:34 CET
David Walser
2020-01-12 17:28:49 CET
CC:
(none) =>
geiger.david68210, nicolas.salguero libjpeg has no registered maintainer; I see other relevant packagers are already CC'd, so assigning this globally for the form. Assignee:
bugsquad =>
pkg-bugs Suggested advisory: ======================== The updated packages fix security vulnerabilities: A signed integer overflow and subsequent segfault that occurred when attempting to decompress images with more than 715827882 pixels using the 64-bit C version of TJBench. Out-of-bounds write in tjDecompressToYUV2() and tjDecompressToYUVPlanes() (sometimes manifesting as a double free) that occurred when attempting to decompress grayscale JPEG images that were compressed with a sampling factor other than 1 (for instance, with cjpeg -grayscale -sample 2x2). A regression introduced by 2.0.2[5] that caused the TurboJPEG API to incorrectly identify some JPEG images with unusual sampling factors as 4:4:4 JPEG images. This was known to cause a buffer overflow when attempting to decompress some such images using tjDecompressToYUV2() or tjDecompressToYUVPlanes(). An issue, detected by ASan, whereby attempting to losslessly transform a specially-crafted malformed JPEG image containing an extremely-high-frequency coefficient block (junk image data that could never be generated by a legitimate JPEG compressor) could cause the Huffman encoder's local buffer to be overrun. References: https://github.com/libjpeg-turbo/libjpeg-turbo/releases/tag/2.0.4 ======================== Updated packages in core/updates_testing: ======================== lib(64)jpeg8-2.0.4-1.mga7 lib(64)jpeg62-2.0.4-1.mga7 lib(64)turbojpeg0-2.0.4-1.mga7 lib(64)jpeg-devel-2.0.4-1.mga7 lib(64)jpeg-static-devel-2.0.4-1.mga7 jpeg-progs-2.0.4-1.mga7 from SRPMS: libjpeg-2.0.4-1.mga7.src.rpm Status:
NEW =>
ASSIGNED Mga7-64 Plasma on Lenovo B50 No installation issues Ref to my tests in bug 23238 $ djpeg -verbose -bmp DSCN0474.JPG > DSCN0474.bmp libjpeg-turbo version 2.0.4 (build 20200113) Copyright (C) 2009-2019 D. R. Commander Copyright (C) 2011-2016 Siarhei Siamashka Copyright (C) 2015-2016, 2018 Matthieu Darbois Copyright (C) 2015 Intel Corporation Copyright (C) 2015 Google, Inc. Copyright (C) 2013-2014 MIPS Technologies, Inc. Copyright (C) 2013 Linaro Limited Copyright (C) 2009-2011 Nokia Corporation and/or its subsidiary(-ies) Copyright (C) 2009 Pierre Ossman for Cendio AB Copyright (C) 1999-2006 MIYASAKA Masaru Copyright (C) 1991-2016 Thomas G. Lane, Guido Vollbeding Emulating The Independent JPEG Group's software, version 8d 15-Jan-2012 Start of Image Miscellaneous marker 0xe1, length 61716 Define Quantization Table 0 precision 0 Define Quantization Table 1 precision 0 Define Huffman Table 0x00 Define Huffman Table 0x01 Define Huffman Table 0x10 Define Huffman Table 0x11 Start Of Frame 0xc0: width=5152, height=3864, components=3 Component 1: 2hx1v q=0 Component 2: 1hx1v q=1 Component 3: 1hx1v q=1 Start Of Scan: 3 components Component 1: dc=0 ac=0 Component 2: dc=1 ac=1 Component 3: dc=1 ac=1 Ss=0, Se=63, Ah=0, Al=0 End Of Image $ display DSCN0474.bmp display is OK $ cjpeg -grayscale -verbose DSCN0474.bmp > gray1.jpg libjpeg-turbo version 2.0.4 (build 20200113) Copyright (C) 2009-2019 D. R. Commander Copyright (C) 2011-2016 Siarhei Siamashka Copyright (C) 2015-2016, 2018 Matthieu Darbois Copyright (C) 2015 Intel Corporation Copyright (C) 2015 Google, Inc. Copyright (C) 2013-2014 MIPS Technologies, Inc. Copyright (C) 2013 Linaro Limited Copyright (C) 2009-2011 Nokia Corporation and/or its subsidiary(-ies) Copyright (C) 2009 Pierre Ossman for Cendio AB Copyright (C) 1999-2006 MIYASAKA Masaru Copyright (C) 1991-2016 Thomas G. Lane, Guido Vollbeding Emulating The Independent JPEG Group's software, version 8d 15-Jan-2012 5152x3864 24-bit BMP image $ display gray1.jpg display is OK $ jpegtran -rotate 90 gray1.jpg > gray2.jpg $ display gray2.jpg display is OK All images show up OK in gwenview as well. CC:
(none) =>
herman.viaene Validating. Advisory in Comment 2. CC:
(none) =>
andrewsfarm, sysadmin-bugs
Thomas Backlund
2020-01-17 10:48:58 CET
CC:
(none) =>
tmb An update for this issue has been pushed to the Mageia Updates repository. https://advisories.mageia.org/MGASA-2020-0040.html Resolution:
(none) =>
FIXED CVE-2019-2201 was fixed in this update: https://www.debian.org/lts/security/2022/dla-3037 > An issue, detected by ASan, whereby attempting to losslessly transform a > specially-crafted malformed JPEG image containing an > extremely-high-frequency coefficient block (junk image data that could never > be generated by a legitimate JPEG compressor) could cause the Huffman > encoder's local buffer to be overrun. This issue was CVE-2020-17541: https://github.com/libjpeg-turbo/libjpeg-turbo/releases/tag/2.0.4 https://ubuntu.com/security/notices/USN-5553-1 |