Bundled OpenEXR 3.2.0 is affected by CVE-2023-5841

[musicinmybrain]

Description of Issue

See AcademySoftwareFoundation/openexr#1625 and https://takeonme.org/cves/CVE-2023-5841.html.

A proposed fix is available in AcademySoftwareFoundation/openexr#1627.

Steps to Reproduce

Observe that a slightly forked version of OpenEXR 3.2.0 is bundled in https://github.com/PixarAnimationStudios/OpenUSD/tree/v23.11/pxr/imaging/hio/OpenEXR, and compare with AcademySoftwareFoundation/openexr#1625 and https://takeonme.org/cves/CVE-2023-5841.html.

System Information (OS, Hardware)

N/A

Package Versions

23.11

Build Flags

N/A

[jesschimein]

Filed as internal issue #USD-9261

[meshula]

Hi, thanks for the report. We can update our copy once the fix has been tagged in a release at the OpenEXR project.

Please note that the reported issue affects deep pixel tiled images; deep pixel images are not read or supported by Hydra as a texture input, so the code path addressed by this CVE and the proposed fix are not able to be exercised from OpenUSD. In the future it's possible we would support deep pixels, and picking up the fix when it is published will safe guard against that possibility.

[musicinmybrain]

Hi, thanks for the report. We can update our copy once the fix has been tagged in a release at the OpenEXR project.

Please note that the reported issue affects deep pixel tiled images; deep pixel images are not read or supported by Hydra as a texture input, so the code path addressed by this CVE and the proposed fix are not able to be exercised from OpenUSD. In the future it's possible we would support deep pixels, and picking up the fix when it is published will safe guard against that possibility.

Thanks for this detailed and useful assessment. As a co-maintainer of the usd package in Fedora, this helped me decide that I probably shouldn’t patch in the proposed fix right away, and I don’t necessarily need to do anything about CVE-2023-5841 other than wait for a future OpenUSD release to contain an updated OpenEXR.

[musicinmybrain]

Hmm, the commit message of 8d2d14d claims it’s an update to OpenEXR 3.4, but it looks like all of the actual source code derived from OpenEXR is unchanged in that commit. Furthermore, the OpenEXR version header still reports 3.2.0 even in the latest dev branch:

OpenUSD/pxr/imaging/plugin/hioOpenEXR/OpenEXR/OpenEXRCore/openexr_version.h

Lines 11 to 13 in dbda7a2

	# define OPENEXR_VERSION_MAJOR 3
	# define OPENEXR_VERSION_MINOR 2
	# define OPENEXR_VERSION_PATCH 0

It looks to me as if the bundled OpenEXR code was never actually rebased on the upstream 3.4.0 release.

[meshula]

Hi! Thanks for your attention to CVEs.

There is no access path to the affected deep scanline code, so it is not possible to be vulnerable to the reported fault.

[meshula]

Also, the committed version is 3.4

8d2d14d

I can see that I did not update the version file, at that time. I apparently neglected to regenerate it.

Thanks for the catch.

[musicinmybrain]

Thanks for checking. What confused me about the “OpenEXR 3.4” commit was that the entire contents of imaging/hio/OpenEXR/ were apparently moved to hioOpenEXR/OpenEXR/ with no changes at all to any of the source files, even though nearly all of them were modified upstream between 3.2.0 and 3.4.0. I can’t find any of the upstream changes from 3.2.0 to 3.4.0, not just the version file.

(I do see e1e1d52, prior to the “OpenEXR 3.4” commit, which does seem to have backported the fix for this particular CVE, so I agree at least that this bug seems to be fixed.)

[musicinmybrain]

For example, I was looking at https://www.cve.org/CVERecord?id=CVE-2026-34543, which is fixed by AcademySoftwareFoundation/openexr@5f6d0aa. That applies against OpenEXR 3.4.0, but it’s hard to confidently backport it to the OpenEXR 3.4.0 bundled here because compression.c doesn’t have the additonal libdeflate_zlib_decompress_ex return-value branches introduced in 3.4.0. Compare OpenEXR 3.4.0:

https://github.com/AcademySoftwareFoundation/openexr/blob/v3.4.0/src/lib/OpenEXRCore/compression.c#L193-L209

with OpenEXR 3.2.0:

https://github.com/AcademySoftwareFoundation/openexr/blob/v3.2.0/src/lib/OpenEXRCore/compression.c#L149-L156

…and then with the bundled copy, which looks just like 3.2.0:

https://github.com/PixarAnimationStudios/OpenUSD/blob/v26.03/pxr/imaging/plugin/hioOpenEXR/OpenEXR/OpenEXRCore/compression.c#L150-L157