Arch Linux

Please read this before reporting a bug:

Do NOT report bugs when a package is just outdated, or it is in the AUR. Use the 'flag out of date' link on the package page, or the Mailing List.

REPEAT: Do NOT report bugs for outdated packages!

FS#68939 - [openjpeg2] [Security] multiple issues (AVG-1343)

Attached to Project: Arch Linux
Opened by Jonas Witschel (diabonas) - Friday, 11 December 2020, 13:10 GMT
Last edited by Andreas Radke (AndyRTR) - Tuesday, 29 December 2020, 07:28 GMT
Task Type Bug Report
Category Security
Status Closed
Assigned To Andreas Radke (AndyRTR)
Architecture All
Severity Medium
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 1
Private No



The package openjpeg2 is vulnerable to multiple issues including arbitrary code execution and denial of service via CVE-2020-27824, CVE-2020-27814, CVE-2020-15389, CVE-2020-8112, CVE-2020-6851, CVE-2019-12973, CVE-2019-6988, CVE-2018-20846 and CVE-2018-16376.


After the last vulnerability report ( FS#68906 ), I dug a little deeper and discovered that openjpeg has gathered quite a few security issues since its last release 2.3.1 in April 2019. I have collected all the CVEs I could find in the linked security tracker entry. The necessary patches are: # CVE-2019-12973 # CVE-2019-12973 # CVE-2020-6851 # CVE-2020-8112 # CVE-2020-15389 # CVE-2020-27814 # CVE-2020-27824

CVE-2018-16376 and CVE-2019-6988 appear to have no upstream fixes, CVE-2018-20846 had one ( which was later reverted ( because it did not compile.

Given the relatively large number of patches, I think this might be one of the few cases where packaging the current master (currently at commit 98a4c5c3709e0cc43b0a1c151ed5bd85a2d607fa, including all these fixes) might be easier.

This task depends upon

Closed by  Andreas Radke (AndyRTR)
Tuesday, 29 December 2020, 07:28 GMT
Reason for closing:  Fixed
Additional comments about closing:  2.4.0
Comment by Andreas Radke (AndyRTR) - Friday, 11 December 2020, 14:06 GMT
How about kicking upstream to do stable release? It seems to be one of the projects that sadly doesn't follow "release early & release often".

I have no clue if master is in a good backward compatible shape or might break something.
Comment by Jonas Witschel (diabonas) - Friday, 11 December 2020, 14:20 GMT
I agree that a new release would be the best option, but am unsure how to approach upstream: the maintainer acknowledges the need for a new release (, but hasn't cut one in over a year and doesn't seem overly receptive to upstream issues asking for one (, FWIW, the person reporting some of the more recent security issues asked for a new release two weeks ago:
Comment by Jonas Witschel (diabonas) - Tuesday, 15 December 2020, 14:18 GMT
Some more CVEs have been assigned: # CVE-2020-27841 # CVE-2020-27841 # CVE-2020-27842 # CVE-2020-27843 # CVE-2020-27845

The fixes for CVE-2020-27842 and CVE-2020-27843 are possibly only stopgap solutions according to their commit description.

There is also CVE-2020-27844, see, but this issue probably only affects the current master according to the commit description since the vulnerable code is not present in any released version.