Bug 2262398

Use the following template to for the 'fedpkg update' request to submit an
update for this issue as it contains the top-level parent bug(s) as well as
this tracking bug.  This will ensure that all associated bugs get updated
when new packages are pushed to stable.

=====

# bugfix, security, enhancement, newpackage (required)
type=security

# low, medium, high, urgent (required)
severity=high

# testing, stable
request=testing

# Bug numbers: 1234,9876
bugs=2262397,2262398

# Description of your update
notes=Security fix for [PUT CVEs HERE]

# Enable request automation based on the stable/unstable karma thresholds
autokarma=True
stable_karma=3
unstable_karma=-3

# Automatically close bugs when this marked as stable
close_bugs=True

# Suggest that users restart after update
suggest_reboot=False

======

Additionally, you may opt to use the bodhi web interface to submit updates:

https://bodhi.fedoraproject.org/updates/new

USD does bundle an affected version of OpenEXR, 3.2.0, in F39 and later. As described in https://github.com/PixarAnimationStudios/OpenUSD/blob/v23.11/pxr/imaging/hio/OpenEXR/README.md, the OpenEXR library is slightly forked, and it’s not possible to use a system copy. (The system copy is currently older than the bundled copy anyway, at 3.1.10.)

In F38, USD was able to use the system copy of OpenEXR rather than bundling, but the openexr package is of course affected there too.

The bundled OpenEXR is still based on 3.2.0 in USD upstream in both the release and dev branches. Furthermore, the current OpenEXR release (3.2.1) is listed as affected, and https://github.com/AcademySoftwareFoundation/openexr currently has no issues, pull requests, or unreleased commits that appear to be related to this CVE.

If a fix appears in OpenEXR upstream, I can look at it to see if is possible to backport it to the USD-bundled copy. If so, I may be able to send a PR upstream to USD and possibly apply a patch to the Fedora package. Until then, though, there is nothing I can do, since I don’t plan to try to write a fix for the issue myself.

OpenUSD upstream agrees that the bundled OpenExr 3.2.0 is affected. However:

> 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.

Based on this assessment, it doesn’t make sense to patch this package before the OpenEXR maintainers have fully verified the fix. It probably isn’t necessary to patch it at all.

I’m therefore closing this as NOTABUG, not because the usd package does not *contain* the OpenEXR code in question, but because OpenUSD upstream judged that the code in question was not reachable. Patching in the fix is definitely *feasible*, though, so if someone believes this is choice is an error, please reopen.