From URL: * OSS-fuzz [39198](https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=39198) Direct-leak in exr_attr_chlist_add_with_length * OSS-fuzz [39206](https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=39206) Direct-leak in extract_attr_string_vector * OSS-fuzz [39212](https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=39212) Heap-use-after-free in dispatch_print_error * OSS-fuzz [39205](https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=39205) Timeout in openexr_exrcheck_fuzzer * OSS-fuzz [38912](https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=38912) Integer-overflow in Imf_3_1::bytesPerDeepLineTable * OSS-fuzz [39084](https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=39084) Divide-by-zero in Imf_3_1::RGBtoXYZ Fixed in 3.1.2, please bump.
Thanks, already working on bumping imath and openexr to 3.1.3.
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=c3d9d27ae6bcab1323ec53edeea148e974a26f7a commit c3d9d27ae6bcab1323ec53edeea148e974a26f7a Author: Bernd Waibel <waebbl-gentoo@posteo.net> AuthorDate: 2021-10-11 19:19:07 +0000 Commit: Sam James <sam@gentoo.org> CommitDate: 2021-10-17 02:22:00 +0000 media-libs/openexr: bump to 3.1.2 Version contains security fixes. Docs are now build with doxygen, pre-generated pdf docs are no longer shipped. Bug: https://bugs.gentoo.org/817431 Package-Manager: Portage-3.0.28, Repoman-3.0.3 Signed-off-by: Bernd Waibel <waebbl-gentoo@posteo.net> Signed-off-by: Sam James <sam@gentoo.org> media-libs/openexr/Manifest | 1 + media-libs/openexr/openexr-3.1.2.ebuild | 77 +++++++++++++++++++++++++++++++++ 2 files changed, 78 insertions(+)
Shall we go and stabilize it already?
Sanity check failed: > media-libs/openexr-3.1.2 > depend amd64 dev profile default/linux/amd64/17.0/x32 (2 total) > >=dev-libs/imath-3.1.0:= > depend amd64 stable profile default/linux/amd64/17.1 (43 total) > >=dev-libs/imath-3.1.0:= > rdepend amd64 dev profile default/linux/amd64/17.0/x32 (2 total) > >=dev-libs/imath-3.1.0:= > rdepend amd64 stable profile default/linux/amd64/17.1 (43 total) > >=dev-libs/imath-3.1.0:=
Keywords are not fully specified and arches are not CC-ed for the following packages: - =media-libs/openexr-3.1.2
Not in this bug, please.
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=e6438b6de1d7c84680e5e00d68c1fb6112dbc05d commit e6438b6de1d7c84680e5e00d68c1fb6112dbc05d Author: Andreas Sturmlechner <asturm@gentoo.org> AuthorDate: 2022-01-09 14:56:18 +0000 Commit: Andreas Sturmlechner <asturm@gentoo.org> CommitDate: 2022-01-09 15:47:59 +0000 media-libs/openexr: Cleanup vulnerable/overshadowed 3.1.1 Bug: https://bugs.gentoo.org/817431 Package-Manager: Portage-3.0.30, Repoman-3.0.3 Signed-off-by: Andreas Sturmlechner <asturm@gentoo.org> media-libs/openexr/Manifest | 1 - media-libs/openexr/openexr-3.1.1.ebuild | 78 --------------------------------- 2 files changed, 79 deletions(-)
Please cleanup, thanks!
IMO there's nothing left to cleanup. Andreas thankfully already cleaned the vulnerable 3.1.1
Is 2.5.7 unaffected?
I'm not absolutely sure about this, but I think so. Upstream usually backports security fixes to v2.5 as it's the last v2 version which is still maintained and there's no later release upstream than 2.5.7. Plus, openexr-2 is not mentioned in any of the oss-fuzz reports, so I assume And we currently can't easily remove slot 0 of openexr. This would break a lot of packages, because most of the packages / ebuilds which depend on it, are still not ported to use openexr:3.
On a second thought, it's possible, that the reporters didn't care about the outdated / obsolete v2.5 and didn't test against it. So maybe it's not known whether this version is vulnerable or not. I can ask upstream about it. I was already thinking of retiring slot 0, but even packages like the latest blender, for which EXR is an important file format and which is very actively developed hasn't updated to support v3.
It's not unheard of to wait for security cleanup thanks to revdeps lagging, so we can easily wait here if necessary.
CVE-2021-3933 (https://bugzilla.redhat.com/show_bug.cgi?id=2019783): An integer overflow could occur when OpenEXR processes a crafted file on systems where size_t < 64 bits. This could cause an invalid bytesPerLine and maxBytesPerLine value, which could lead to problems with application stability or lead to other attack paths. CVE-2021-3941 (https://bugzilla.redhat.com/show_bug.cgi?id=2019789): In ImfChromaticities.cpp routine RGBtoXYZ(), there are some division operations such as `float Z = (1 - chroma.white.x - chroma.white.y) * Y / chroma.white.y;` and `chroma.green.y * (X + Z))) / d;` but the divisor is not checked for a 0 value. A specially crafted file could trigger a divide-by-zero condition which could affect the availability of programs linked with OpenEXR.
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=5a1d9ccaaa866fd0a831653dc92588fc59be0085 commit 5a1d9ccaaa866fd0a831653dc92588fc59be0085 Author: Bernd Waibel <waebbl-gentoo@posteo.net> AuthorDate: 2022-03-14 06:01:38 +0000 Commit: Andreas Sturmlechner <asturm@gentoo.org> CommitDate: 2022-04-10 21:01:49 +0000 media-libs/openexr: drop 3.1.2, 3.1.3, 3.1.4 Cleanup old and vulnerable slot 3 versions. Bug: https://bugs.gentoo.org/817431 Bug: https://bugs.gentoo.org/820674 Bug: https://bugs.gentoo.org/830384 Closes: https://bugs.gentoo.org/833158 Signed-off-by: Bernd Waibel <waebbl-gentoo@posteo.net> Signed-off-by: Andreas Sturmlechner <asturm@gentoo.org> media-libs/openexr/Manifest | 2 - ...1-0001-changes-needed-for-proper-slotting.patch | 119 ---------- ...0002-add-version-to-binaries-for-slotting.patch | 252 --------------------- media-libs/openexr/openexr-3.1.2.ebuild | 78 ------- media-libs/openexr/openexr-3.1.3.ebuild | 78 ------- media-libs/openexr/openexr-3.1.4.ebuild | 78 ------- 6 files changed, 607 deletions(-)
