More information about this security flaw is available in the following bug: http://bugzilla.redhat.com/show_bug.cgi?id=2262397 Disclaimer: Community trackers are created by Red Hat Product Security team on a best effort basis. Package maintainers are required to ascertain if the flaw indeed affects their package, before starting the update process.
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.