There's a flaw in OpenEXR's ImfDeepScanLineInputFile functionality in versions prior to 3.0.5. An attacker who is able to submit a crafted file to an application linked with OpenEXR could cause an out-of-bounds read. The greatest risk from this flaw is to application availability.
So, the RedHat bug says this is a buffer overflow, the upstream issue 
says this is a buffer overflow, but RedHat's CVE says this is a buffer
overread. This is OpenEXR too so no doubt will be more fuzzer bugs once this
AFAICS this will also be fixed in post 2.5.7 release for <v3 releases, see https://github.com/AcademySoftwareFoundation/openexr/pull/1040.
For v3 releases, there's a PR I'm working on for implementing slots for openexr. I'll add this bug, next time I push.
The bug has been referenced in the following commit(s):
Author: Bernd Waibel <email@example.com>
AuthorDate: 2021-05-21 23:12:34 +0000
Commit: Marek Szuba <firstname.lastname@example.org>
CommitDate: 2021-07-21 21:57:28 +0000
media-libs/openexr: bump to 3.0.5
Improves slotting, so that openexr-2 and openexr-3
can be installed in parallel.
Drop multilib support. Only multilib-aware consumer was
media-libs/opencv. Using multilib would require it on
dev-libs/imath as well which is not possible.
Package-Manager: Portage-3.0.20, Repoman-3.0.3
Signed-off-by: Bernd Waibel <email@example.com>
Signed-off-by: Marek Szuba <firstname.lastname@example.org>
media-libs/openexr/Manifest | 1 +
...5-0001-changes-needed-for-proper-slotting.patch | 119 +++++++++++
...0002-add-version-to-binaries-for-slotting.patch | 229 +++++++++++++++++++++
media-libs/openexr/openexr-3.0.5.ebuild | 77 +++++++
4 files changed, 426 insertions(+)
According to https://github.com/AcademySoftwareFoundation/openexr/blob/v3.0.5/CHANGES.md#version-305-july-1-2021 the above issue has been closed by PR #1037, which is referenced for 3.0.5.
It should also be solved in 2.5.7, c.f. https://github.com/AcademySoftwareFoundation/openexr/blob/RB-2.5/CHANGES.md#version-257-june-16-2021
(In reply to John Helmert III from comment #0)
> This is OpenEXR too so no doubt will be more fuzzer bugs once this
> is released.
Maybe I was wrong!
There are only two oss-fuzz issues in 2.5.7 changelog:
OSS-fuzz 28051 Heap-buffer-overflow in Imf_2_5::copyIntoFrameBuffer
OSS-fuzz 28155 Crash in Imf_2_5::PtrIStream::read
Then 3.0.5 only says
1036 detect buffer overflows in RleUncompress
3.0.5 and 2.5.7 both speak of
1037 verify data size in deepscanlines with NO_COMPRESSION
which is the PR that solves issue #1033, referenced in your description.
https://cve.mitre.org/cgi-bin/cvename.cgi?name=2021-3598 only speaks of 3.0.5, but from the reference in CHANGES.md, I suppose, 2.5.7 has it solved as well.
(In reply to Bernd from comment #5)
> 3.0.5 and 2.5.7 both speak of
> 1037 verify data size in deepscanlines with NO_COMPRESSION
> which is the PR that solves issue #1033, referenced in your description.
> https://cve.mitre.org/cgi-bin/cvename.cgi?name=2021-3598 only speaks of
> 3.0.5, but from the reference in CHANGES.md, I suppose, 2.5.7 has it solved
> as well.
I agree. The CVE is wrong. I don't suppose RedHat cares.
Package list is empty or all packages have requested keywords.