A vulnerability was found in jbig2_image_compose in jbig2_image.c in Artifex jbig2dec before 0.18 has a heap-based buffer overflow. References: https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=20332 https://github.com/ArtifexSoftware/jbig2dec/commit/0726320a4b55078e9d8deb590e477d598b3da66e https://github.com/ArtifexSoftware/jbig2dec/compare/0.17...0.18
Created jbig2dec tracking bugs for this issue: Affects: fedora-all [bug 1848520]
Created jbig2dec tracking bugs for this issue: Affects: epel-all [bug 1848522]
Upstream fix: https://github.com/ArtifexSoftware/jbig2dec/commit/0726320a4b55078e9d8deb590e477d598b3da66e
Due to an integer overflow during a multiplication used in jbig2_image_compose(), it is possible to cause an out-of-bound read/write in the jbig2dec library, which could potentially result in the execution of code on the system. Applications that use jbig2dec with untrusted input may be vulnerable to this flaw.
Red Hat Enterprise Linux 8 just ships jbig2dec-libs, so no custom application can be built against this library, however there are existing packages that use jbig2dec-libs, such as libgs, which in turn is used by ghostscript, graphviz, gimp and others.
I'm sorry I can't make much sense out of these bug reports against old versions. As far as I can see, everything is (well: all those reported bugs are) fixed in current releases and there is no jbig2dec in epel8. I have no control over jbig2dec-libs in epel8, and in fact that held up getting jbig2dec into epel8. epel7 is based on an ancient Fedora. The RHEL/EPEL criteria keep me from updating any epel package to current versions. This basically contradicts having *any* artifex software in EPEL: it is notoriously buggy, there are no maintenance (bugfix) branches, and parts like jbig2dec have no abi stability whatsover, which practically requires packagers to update to *the* current release, hopefully coordinating with other packagers if they don't have their dependencies explicit enough. This does not scale and is too complicated for me poor little fedora maintainer. In short: - As much of artifex's stuff should be in the hands of very few developpers. - EPEL requirements do not match my time constraints. Feel free to take any EPEL branches that are currently assigned to me. (We used to be able to simply give them away, nowadays it's tickets, I guess.)
In reply to comment #8: > I'm sorry I can't make much sense out of these bug reports against old > versions. > > As far as I can see, everything is (well: all those reported bugs are) fixed > in current releases and there is no jbig2dec in epel8. > I have no control over jbig2dec-libs in epel8, and in fact that held up > getting jbig2dec into epel8. Those bugs are not only for Fedora 32 or EPEL 8, but for all supported Fedora/EPEL. So, for example, Fedora 31, which is still supported, ships jbig2dec-0.16, which is potentially vulnerable to this flaw. As part of our process, we notify maintainers in community projects about the (possible) issue, but then it is up to you to choose what to do. > epel7 is based on an ancient Fedora. The RHEL/EPEL criteria keep me from > updating any epel package to current versions. This basically contradicts > having *any* artifex software in EPEL: it is notoriously buggy, there are no > maintenance (bugfix) branches, and parts like jbig2dec have no abi stability > whatsover, which practically requires packagers to update to *the* current > release, hopefully coordinating with other packagers if they don't have > their dependencies explicit enough. This does not scale and is too > complicated for me poor little fedora maintainer. > > In short: > - As much of artifex's stuff should be in the hands of very few developpers. > - EPEL requirements do not match my time constraints. As said, we notify maintainers about the possible security issues, then it is up to you if, when and how to address them. Some will backport the fixes, others will update to current release, some may be able to fix it only on latest version of the project (e.g. Fedora 32) and not on all of them. Of course we can't know how each component works upstream, whether it is easy or not for you to backport the patch or fix it somehow. > Feel free to take any EPEL branches that are currently assigned to me. (We > used to be able to simply give them away, nowadays it's tickets, I guess.) What does this mean exactly?
This issue has been addressed in the following products: Red Hat Enterprise Linux 8 Via RHSA-2020:2897 https://access.redhat.com/errata/RHSA-2020:2897
This bug is now closed. Further updates for individual products will be reflected on the CVE page(s): https://access.redhat.com/security/cve/cve-2020-12268
This issue has been addressed in the following products: Red Hat Enterprise Linux 8.1 Extended Update Support Via RHSA-2020:2971 https://access.redhat.com/errata/RHSA-2020:2971
This issue has been addressed in the following products: Red Hat Enterprise Linux 8.0 Update Services for SAP Solutions Via RHSA-2020:3043 https://access.redhat.com/errata/RHSA-2020:3043