Bug 29127 - openjpeg2 new security issue CVE-2021-3575
Summary: openjpeg2 new security issue CVE-2021-3575
Alias: None
Product: Mageia
Classification: Unclassified
Component: Security (show other bugs)
Version: 8
Hardware: All Linux
Priority: Normal major
Target Milestone: ---
Assignee: QA Team
QA Contact: Sec team
Whiteboard: MGA7TOO MGA7-64-OK MGA8-64-OK
Keywords: advisory, validated_update
Depends on:
Reported: 2021-06-14 00:16 CEST by David Walser
Modified: 2021-06-28 23:18 CEST (History)
4 users (show)

See Also:
Source RPM: openjpeg2-2.4.0-1.1.mga8.src.rpm
CVE: CVE-2021-3575
Status comment:


David Walser 2021-06-14 00:16:45 CEST

Status comment: (none) => Patch available from Fedora
CC: (none) => geiger.david68210
Whiteboard: (none) => MGA8TOO, MGA7TOO

Comment 1 Lewis Smith 2021-06-14 21:17:25 CEST
Another one for you, David. You are even the registered (as well as actual) maintainer of this!

CC: geiger.david68210 => (none)
Assignee: bugsquad => geiger.david68210

Comment 2 David Walser 2021-06-27 22:50:46 CEST

Updated openjpeg2 packages fix security vulnerability:

A heap-based buffer overflow was found in openjpeg. An attacker could use this
to execute arbitrary code with the permissions of the application compiled
against openjpeg (CVE-2021-3575).


Updated packages in core/updates_testing:

from SRPMS:

Whiteboard: MGA8TOO, MGA7TOO => MGA7TOO
CC: (none) => geiger.david68210
Version: Cauldron => 8
Status comment: Patch available from Fedora => (none)
Assignee: geiger.david68210 => qa-bugs

Comment 3 Len Lawrence 2021-06-28 18:20:27 CEST
mga8, x86_64

Could not find anything useful for the CVE.
Updated the three packages and ran some of the utilities.

$ opj_compress -i Ikapati.bmp -o ikapati.jp2
[INFO] tile number 1 / 1
[INFO] Generated outfile ikapati.jp2
encode time: 86 ms 

The output file displayed correctly.

$ opj_dump -i ikapati.jp2 -o imagedata
[INFO] Start to read j2k main header (85).
[INFO] Main header has been correctly decoded.
$ less imagedata
Image info {
         x0=0, y0=0
         x1=614, y1=614
Codestream index from main header: {
         Main header start position=85
         Main header end position=204
         Marker list: {
                 type=0xff4f, pos=85, len=2
                 type=0xff51, pos=87, len=43
                 type=0xff52, pos=130, len=14
                 type=0xff5c, pos=144, len=21
                 type=0xff64, pos=165, len=39

$ opj_decompress -i ikapati.jp2 -o ikapati.bmp
[INFO] Start to read j2k main header (85).
[INFO] Main header has been correctly decoded.
[INFO] No decoded area parameters, set the decoded area to the whole image
[INFO] Header of tile 1 / 1 has been read.
[INFO] Stream reached its end !
[INFO] Generated Outfile ikapati.bmp
decode time: 64 ms
$ file *.bmp
ikapati.bmp: PC bitmap, Windows 3.x format, 614 x 614 x 8, image size 376996, resolution 7834 x 7834 px/m, 256 important colors, cbSize 378074, bits offset 1078
Ikapati.bmp: PC bitmap, Windows 3.x format, 614 x 614 x 8, image size 376996, resolution 7834 x 7834 px/m, 256 important colors, cbSize 378074, bits offset 1078

The doubly converted file matches the original perfectly.

A number of applications may require lib64openjp2_7 including darktable, blender and the GIMP.
Pointed darktable at an image and examined it in the darkroom.  Applied velvia to amplify the mid-tone bias (?) which generated a warmer, brighter image.
$ grep jp2 darktable.trace | grep -v jessica
openat(AT_FDCWD, "/lib64/libopenjp2.so.7", O_RDONLY|O_CLOEXEC) = 3
read(14, "ibopenjp2.so.2.4.0\n7fc1ba374000-"..., 1024) = 1024

Giving this an OK.

Whiteboard: MGA7TOO => MGA7TOO MGA8-64-OK
CC: (none) => tarazed25

Comment 4 Len Lawrence 2021-06-28 19:54:26 CEST
mga7, x64

Updated the three packages and ran similar tests to those in comment 3 and saw the same sort of results.
Used gimp on another jp2 image, scaled it and sheared it and saved it to xcf format which displayed correctly using ImageMagick.

$ grep jp2 gimp.trace | grep -v piuva
openat(AT_FDCWD, "/lib64/libopenjp2.so.7", O_RDONLY|O_CLOEXEC) = 4
openat(AT_FDCWD, "/lib64/libopenjp2.so.7", O_RDONLY|O_CLOEXEC) = 4
stat("/usr/lib64/gegl-0.4/jp2-load.so", {st_mode=S_IFREG|0755, st_size=24064, ...}) = 0
stat("/usr/lib64/gegl-0.4/jp2-load.so", {st_mode=S_IFREG|0755, st_size=24064, ...}) = 0
openat(AT_FDCWD, "/usr/lib64/gegl-0.4/jp2-load.so", O_RDONLY|O_CLOEXEC) = 4

$ file piuva.xcf
piuva.xcf: GIMP XCF image data, version 011, 640 x 680, RGB Color

Looks good for Mageia 7 as well.
Len Lawrence 2021-06-28 19:54:41 CEST

Whiteboard: MGA7TOO MGA8-64-OK => MGA7TOO MGA7-64-OK MGA8-64-OK

Comment 5 Aurelien Oudelet 2021-06-28 20:54:13 CEST
Advisory comment 2.

Keywords: (none) => advisory, validated_update
CVE: (none) => CVE-2021-3575
Source RPM: openjpeg2-2.4.0-2.mga9.src.rpm => openjpeg2-2.4.0-1.1.mga8.src.rpm
CC: (none) => ouaurelien, sysadmin-bugs

Comment 6 Mageia Robot 2021-06-28 23:18:26 CEST
An update for this issue has been pushed to the Mageia Updates repository.


Resolution: (none) => FIXED

Note You need to log in before you can comment on or make changes to this bug.