OpenEXR 3.4.8__tar.gz → 3.4.9__tar.gz

{openexr-3.4.8 → openexr-3.4.9}/CHANGES.md

@@ -3,6 +3,7 @@
 
 # OpenEXR Release Notes
 
+* [Version 3.4.9](#version-349-april--3-2026) April  3, 2026
 * [Version 3.4.8](#version-348-march-26-2026) March 26, 2026
 * [Version 3.4.7](#version-347-march-15-2026) March 15, 2026
 * [Version 3.4.6](#version-346-march-1-2026) March 1, 2026
@@ -91,6 +92,57 @@
 * [Version 1.0.1](#version-101)
 * [Version 1.0](#version-10)
 
+## Version 3.4.9 (April  3, 2026)
+
+Patch release that addresses several security vulnerabilities.
+
+This release also fixes a build issue where the library symlinks would
+get installed in the incorrect location when overriding the cached
+install prefix path.
+
+This release addresses the following CVEs:
+* [CVE-2026-34589](https://www.cve.org/CVERecord?id=CVE-2026-34589) DWA Lossy Decoder Heap Out-of-Bounds Write
+* [CVE-2026-34588](https://www.cve.org/CVERecord?id=CVE-2026-34588) Signed 32-bit Overflow in PIZ Decoder Leads to OOB Read/Write
+* [CVE-2026-34380](https://www.cve.org/CVERecord?id=CVE-2026-34380) Signed integer overflow (undefined behavior) in undo_pxr24_impl may allow bounds-check bypass in PXR24 decompression
+* [CVE-2026-34379](https://www.cve.org/CVERecord?id=CVE-2026-34379) Misaligned write in LossyDctDecoder_execute leading to undefined behavior (DWA/DWAB decompression)
+* [CVE-2026-34378](https://www.cve.org/CVERecord?id=CVE-2026-34378) Signed integer overflow in generic_unpack() when parsing EXR files with crafted negative dataWindow.min.x
+
+### Merged Pull Requests
+
+* [2329](https://github.com/AcademySoftwareFoundation/openexr/pull/2329)
+Fix signed integer overflow in `LossyDctDecoder_execute()` pointer arithmatic
+* [2328](https://github.com/AcademySoftwareFoundation/openexr/pull/2328)
+fix integer overflow in PIZ wavelet buffer arithmetic
+* [2327](https://github.com/AcademySoftwareFoundation/openexr/pull/2327)
+Add a message about image size limits and OOM errors to SECURITY.md and website
+* [2326](https://github.com/AcademySoftwareFoundation/openexr/pull/2326)
+Fix shared lib symlink installation path
+* [2324](https://github.com/AcademySoftwareFoundation/openexr/pull/2324)
+Fix misaligned memory access in `LossyDctDecoder_execute` HALF→FLOAT expansion
+* [2323](https://github.com/AcademySoftwareFoundation/openexr/pull/2323)
+fix signed integer overflow in `undo_pxr24_impl()`
+* [2321](https://github.com/AcademySoftwareFoundation/openexr/pull/2321)
+Fix integer overflow in `srcbuffer` pointer arithmetic in `unpack_*`
+* [2317](https://github.com/AcademySoftwareFoundation/openexr/pull/2317)
+Add "cherry" and "changes" options to release.py
+
+### Merged Workflow Pull Requests
+
+* [2332](https://github.com/AcademySoftwareFoundation/openexr/pull/2332)
+Bump vmactions/freebsd-vm from 1.4.3 to 1.4.4
+* [2331](https://github.com/AcademySoftwareFoundation/openexr/pull/2331)
+Bump github/codeql-action from 4.34.1 to 4.35.1
+* [2330](https://github.com/AcademySoftwareFoundation/openexr/pull/2330)
+Bump jmertic/slack-release-notifier from f824585541879ef2a6388268eccb9be210aa6878 to 32206e01ee0b0f66865d2be13bb3c62e474b5ce0
+* [2325](https://github.com/AcademySoftwareFoundation/openexr/pull/2325)
+Bump sigstore/gh-action-sigstore-python from 3.2.0 to 3.3.0
+* [2320](https://github.com/AcademySoftwareFoundation/openexr/pull/2320)
+Bump jmertic/slack-release-notifier from 35fad060af5559c24decdec0f701e6ba93566704 to f824585541879ef2a6388268eccb9be210aa6878
+* [2319](https://github.com/AcademySoftwareFoundation/openexr/pull/2319)
+Bump msys2/setup-msys2 from 2.30.0 to 2.31.0
+* [2318](https://github.com/AcademySoftwareFoundation/openexr/pull/2318)
+Bump github/codeql-action from 4.33.0 to 4.34.1
+
 ## Version 3.4.8 (March 26, 2026)
 
 Patch release with several bug/build fixes:

{openexr-3.4.8 → openexr-3.4.9}/CONTRIBUTING.md

@@ -545,83 +545,71 @@ access on the GitHub repo.
 
 The preferred workflow is:
 
-1. Make a PR that merges appropriate changes from the main branch to
-   the release branch:
+1. Cherry-pick commits from the main branch to the release branch,
+   compose release notes, and bump the version number.
 
-   a. In a forked clone, create a branch to hold the patch commits,
-      e.g. ``v3.1.9-fixes``.
+   a. Create a new PR label for the new release (on the GitHub "Pull
+      Request" page), identify all PRs to be included, and assign the
+      label to them.  Run:
 
-   b. Cherry-pick the appropriate commits from ``main``, resolving any
-      merge conflicts.
+          % share/util/release.py log
 
-   c. Increment ``OPENEXR_VERSION_PATCH`` in
-      [src/lib/OpenEXRCore/openexr_version.h](src/lib/OpenEXRCore/openexr_version.h)
-
-   d. Update the ``IMATH_TAG`` setting in
-      [cmake/OpenEXRSetup.cmake](cmake/OpenEXRSetup.cmake) to
-      correspond to the proper Imath release.
-
-   e. Add release notes to [CHANGES.md](CHANGES.md):
-
-      - Generate a list of links to merged pull requests.
-
-        Use ``git log`` to identify the merged commits, and for each
-        commit, and add a link in the notes to the corresponding PR
-        that merged it to ``main``. Citing PR's in the release notes
-        is preferable to citing raw commits because the PR's often
-        have helpful information and discussion missing from the
-        commit descriptions, and the commit history is readily
-        accessible via ``git log`` anyway.
-
-        The typical OpenEXR project workflow uses "squash and merge"
-        to merge PR's into ``main``, so the changes involved in each
-        PR end up on ``main`` as a single commit. This is preferable
-        because a raw PR often includes numerous commits that address
-        comments and feedback or fix typos or mistakes, intermediate
-        steps not helpful to the preserved history of the main
-        development thread. Note that GitHub's "squash and merge"
-        helpfully appends the PR number to the commit subject line.
-
-        Note that when this PR is merged to the release branch, it
-        should go in via "rebase and merge" that the release branch
-        retains the granular changes, described below.
-
-      - Generate a list of OSS-Fuzz issues addressed.
-
-        These are security concerns, so they deserve special
-        attention. Provide a link in the notes to the issue at
-        https://bugs.chromium.org/p/oss-fuzz, including the issue id
-        number and description.
-
-      - If there are any public CVE's, mention them explicitly with a
-        link to the CVE registry item.
-
-      - Provide an executive summary of the patch changes, in a few
-        sentences as well as bullet points if appropriate.
-
-      - Choose a proposed release date at least several days in
-        advance.
-
-   f. If there are any public CVE's, reference them in
-      [SECURITY.md](SECURITY.md).
-
-   g. Submit the PR for others to review. The PR should go *to the
-      release branch, not ``main``*, obviously.
+      to print recent commits and their associated PRs and release
+      labels. The best practice is to ensure that every PR is labeled
+      with the release it should go into, even if that is the next
+      major release.
+   
+      Note that this relies on the commit message having the PR number
+      appended to the end, which GitHub adds on "Squash and
+      merge". PRs merged via "Rebase and merge" do *not* get this PR
+      number, which leaves you to manually decipher the PRs to report
+      in the release notes. Our project policy is to "Squash and
+      merge" whenever possible, unless the PR's individual commits
+      really do need to be preserved in the history.
+
+   b. Identify the main branch commits to cherry pick to the release
+      branch:
+   
+          % share/util/release.py cherry <tag>
+
+      This will print the SHAs for the commits associated with the
+      labeled PRs. The output will look something like:
+      
+          git cherry-pick 2e32c6b # Bump actions/cache from 5.0.3 to 5.0.4 (#2311)
+          git cherry-pick 3df0122 # Pin pypa/cibuildwheel actions to release sha (#2294)
+          git cherry-pick 6155271 # Force macos cibuildwheel to use Xcode clang (#2315)
+          share/util/release.py changes v3.4.8 2311 2294 2315
+          
+   c. Cherry-pick the commits (copy & execute output from `release.py cherry`):
+
+          % git checkout RB-3.4
+          % git cherry-pick 2e32c6b
+          % git cherry-pick 3df0122
+          % git cherry-pick 6155271
+
+      This may involve resolving conflicts along the way. Confirm the
+      updated branch builds successfully.
+
+   d. Create a new section in the `CHANGES.md` release notes file:
+   
+          % share/util/release.py changes <tag> <pr list>
 
-   h. After others have had a chance to sanity-check the changes,
-      merge the PR *with "rebase and merge"*.  Unlike with the usual
-      PR's merged to main, it is essential to retain the individual
-      commits on the release branch. That way, the release branch
-      commit history retains the details of the changes.
+      This is the command as printed at the end of the output of the
+      "cherry" command. This will add a new section to `CHANGES.md`
+      and add entries to the PR lists. Run this from the release
+      branch, since it's preparing a commit for there.
+   
+   e. Edit `CHANGES.md` and compose a release notes summary. Commit
+      this change.
 
-   i. If further fixes come in that need to go into the release, push
-      them to the PR branch. It's not absolutely essential that all
-      changes to the release branch go in via a PR. The PR is simply a
-      convenient forum for publicly discussing and reviewing the
-      composition of the release.
+   f. Bump the version number in
+      `src/lib/OpenEXRCore/openexr_version.h`. Commit this change.
 
+   g. Push the release branch and confirm the CI passes.
+   
 2. Tag the release with a ``-rc`` "release candidate" tag,
-   e.g. ``v3.1.9-rc``.
+   e.g. ``v3.1.9-rc``.  Push the tag via `git push --tags`. This will
+   trigger the release candidate workflow.
 
 3. Validate ABI compatibility. Build at the release candidate tag and
    run
@@ -635,15 +623,13 @@ The preferred workflow is:
    of the release with link to the release candidate tag. Include the
    release notes from [CHANGES.md](CHANGES.md) for review.
 
-5. Draft the release on the GitHub
-   [Releases](https://github.com/AcademySoftwareFoundation/openexr/releases)
-   page.  Include the summary from the notes in
-   [CHANGES.md](CHANGES.md), but don't include the list of PR's.
-
-   Create the release from the latest ``--rc`` tag, and give it a name
-   that begins with ``v``, i.e. ``v3.1.9``.
+5. Draft the GitHub release via:
 
-   Save the release as a "draft".
+        % share/util/release.py draft <tag>
+       
+   Verify the notes look correct on the
+   [Releases](https://github.com/AcademySoftwareFoundation/openexr/releases)
+   page and edit as appropriate. Save as a "draft".
 
 6. Wait at least 48 hours, to give the community time to discover and
    report any obvious problems. Avoid the temptation to rush changes
@@ -652,13 +638,12 @@ The preferred workflow is:
 
    If additional fixes need to go in before release:
 
-   a. Merge commits to the release branch. Push them directly, no need
-      for a pull request.
+   a. Merge commits to the release branch. Push them directly.
 
    b. Update the release notes in a separate commit.
 
    c. Re-tag with a incremented "release candidate" number,
-      e.g. ``v3.1.9-rc2``.  
+      e.g. ``v3.1.9-rc2``.
 
    d. Send an email update to ``openexr-dev@lists.aswf.io`` notifying
       the community of the addition and the new tag.
@@ -671,15 +656,22 @@ The preferred workflow is:
       [registered](https://docs.github.com/en/authentication/managing-commit-signature-verification/telling-git-about-your-signing-key)
       with your GitHub account and git config.
 
-   b. Create a signed tag with the release name via `git tag -s v3.1.9`.
+   b. Create a signed tag with the release name via:
+   
+          git tag -s v3.1.9
 
-   c. Push the tag via `git push --tags`
+   c. Push the tag via:
+
+          git push --tags
 
 8. Publish the release
 
-   a. Click the "Publish release" button on the GitHub release draft
+   a. Set the release to correspond to the latest release candidate
+      tag.
+   
+   b. Click the "Publish release" button on the GitHub release draft
 
-   b. Send an email to ``openexr-dev@lists.aswf.io`` officially
+   c. Send an email to ``openexr-dev@lists.aswf.io`` officially
       announcing the release.
 
 9. Update the ``release`` branch, which should always point to the
@@ -688,9 +680,9 @@ The preferred workflow is:
 
    From a clone of the main repo:
 
-       % git checkout release
-       % git merge RB-3.1
-       % git push
+        % git checkout release
+        % git merge RB-3.1
+        % git push
          
 10. Submit a PR that adds the release notes to [CHANGES.md](CHANGES.md)
     on the main branch. Cherry-pick the release notes commit from
@@ -700,18 +692,25 @@ The preferred workflow is:
       the associated commit as well.
 
     - Also include in this PR edits to [``website/news.rst``](website/news.rst)
-      that add an announcement of the release.
+      that add an announcement of the release:
+
+            share/util/release.py news v3.4.8
 
-11. After review/merge of the updates to ``website/news.rst``, build the
-    website at https://readthedocs.org/projects/openexr.
+      This will edit the website source files to add the news item.
 
+    - Get the PR approved and merged promptly so the news item appears
+      on the website. The website rebuilds automatically at
+      https://readthedocs.org/projects/openexr on changes to the main
+      branch, so no action is required.
+      
 12. If the release has resolved any OSS-Fuzz issues, update the
     associated pages at https://bugs.chromium.org/p/oss-fuzz with a
     reference to the release.
 
-13. If the release has resolved any public CVE's, request an update
+13. If the release has resolved any public CVEs, request an update
     from the registry service providing the release and a link to the
-    release notes.
+    release notes.  Add a reference to resolved public CVEs to
+    `SECURITY.md` and submit as a PR.
 
 ## Creating a Major/Minor Release
 

{openexr-3.4.8 → openexr-3.4.9}/PKG-INFO

@@ -1,6 +1,6 @@
 Metadata-Version: 2.2
 Name: OpenEXR
-Version: 3.4.8
+Version: 3.4.9
 Summary: Python bindings for the OpenEXR image file format
 Author-Email: Contributors to the OpenEXR project <info@openexr.com>
 Project-URL: Homepage, https://openexr.com

{openexr-3.4.8 → openexr-3.4.9}/SECURITY.md

@@ -20,14 +20,32 @@ rapidly and post patches within 14 days if possible.
 
 These vulnerabilities are present in the given versions:
 
+* [CVE-2026-34589](https://www.cve.org/CVERecord?id=CVE-2026-34589)
+  3.2.\*, 3.3.\*,
+  3.4.0, 3.4.1, 3.4.2, 3.4.3, 3.4.4, 3.4.5, 3.4.6, 3.4.7, 3.4.8 
+* [CVE-2026-34588](https://www.cve.org/CVERecord?id=CVE-2026-34588)
+  3.2.\*, 3.3.\*,
+  3.4.0, 3.4.1, 3.4.2, 3.4.3, 3.4.4, 3.4.5, 3.4.6, 3.4.7, 3.4.8 
+* [CVE-2026-34545](https://www.cve.org/CVERecord?id=CVE-2026-34545)
+  3.4.0, 3.4.1, 3.4.2, 3.4.3, 3.4.4, 3.4.5, 3.4.6
+* [CVE-2026-34544](https://www.cve.org/CVERecord?id=CVE-2026-34544)
+  3.4.0, 3.4.1, 3.4.2, 3.4.3, 3.4.4, 3.4.5, 3.4.6, 3.4.7
+* [CVE-2026-34543](https://www.cve.org/CVERecord?id=CVE-2026-34543)
+  3.4.0, 3.4.1, 3.4.2, 3.4.3, 3.4.4, 3.4.5, 3.4.6, 3.4.7
+* [CVE-2026-34380](https://www.cve.org/CVERecord?id=CVE-2026-34380)
+  3.4.0, 3.4.1, 3.4.2, 3.4.3, 3.4.4, 3.4.5, 3.4.6, 3.4.7, 3.4.8 
+* [CVE-2026-34379](https://www.cve.org/CVERecord?id=CVE-2026-34379)
+  3.4.0, 3.4.1, 3.4.2, 3.4.3, 3.4.4, 3.4.5, 3.4.6, 3.4.7, 3.4.8 
+* [CVE-2026-34378](https://www.cve.org/CVERecord?id=CVE-2026-34378)
+  3.4.0, 3.4.1, 3.4.2, 3.4.3, 3.4.4, 3.4.5, 3.4.6, 3.4.7, 3.4.8 
 * [CVE-2026-27622](https://www.cve.org/CVERecord?id=CVE-2026-27622) 2.\*, 3.0.\*, 3.1.\*, 3.2.0, 3.2.1, 3.2.2, 3.2.3, 3.2.4, 3.2.5, 3.3.0, 3.3.1
   3.3.2, 3.3.3, 3.3.4, 3.3.5, 3.3.6, 3.3.7, 3.4.0, 3.4.1, 3.4.2, 3.4.3, 3.4.4, 3.4.5
 * [CVE-2026-26981](https://www.cve.org/CVERecord?id=CVE-2025-64181) 3.3.0, 3.3.1, 3.3.2, 3.3.3, 3.3.4, 3.3.5, 3.3.6, 3.4.0, 3.4.1, 3.4.2, 3.4.3, 3.4.4
-* [CVE-2025-64181](https://www.cve.org/CVERecord?id=CVE-2025-64181) 3.3.0, 3.3.1, 3.3.2, 3.3.3, 3.3.4, 3.3.5, 3.4.0, 3.4.1, 3.4.2
-* [CVE-2025-64182](https://www.cve.org/CVERecord?id=CVE-2025-64182) 3.2.0, 3.2.1, 3.2.3, 3.2.4, 3.3.0, 3.3.1, 3.3.2, 3.3.3, 3.3.4, 3.3.5,
-  3.4.0, 3.4.1, 3.4.2
 * [CVE-2025-64183](https://www.cve.org/CVERecord?id=CVE-2025-64183) 3.2.0, 3.2.1, 3.2.3, 3.2.4, 3.3.0, 3.3.1, 3.3.2, 3.3.3, 3.3.4, 3.3.5,
   3.4.0, 3.4.1, 3.4.2
+* [CVE-2025-64182](https://www.cve.org/CVERecord?id=CVE-2025-64182) 3.2.0, 3.2.1, 3.2.3, 3.2.4, 3.3.0, 3.3.1, 3.3.2, 3.3.3, 3.3.4, 3.3.5,
+  3.4.0, 3.4.1, 3.4.2
+* [CVE-2025-64181](https://www.cve.org/CVERecord?id=CVE-2025-64181) 3.3.0, 3.3.1, 3.3.2, 3.3.3, 3.3.4, 3.3.5, 3.4.0, 3.4.1, 3.4.2
 * [CVE-2025-48074](https://www.cve.org/CVERecord?id=CVE-2025-48074) 3.3.2
 * [CVE-2025-48073](https://www.cve.org/CVERecord?id=CVE-2025-48073) 3.3.2
 * [CVE-2025-48072](https://www.cve.org/CVERecord?id=CVE-2025-48072) 3.3.2
@@ -82,6 +100,7 @@ security vulnerabilities.
 | Version / branch  | Supported                                            |
 |-------| ---------------------------------------------------- |
 | main  | :white_check_mark: :construction: All fixes immediately, although this branch is under development with potential unstable ABI/API
+| 3.4.x | :white_check_mark: All fixes that can be backported without breaking ABI compatibility
 | 3.3.x | :white_check_mark: All fixes that can be backported without breaking ABI compatibility
 | 3.2.x | :warning: Patch releases considered in response to specific requests
 | 3.1.x | :warning: Patch releases considered in response to specific requests
@@ -163,6 +182,32 @@ library. Malformed images could caused issues such as heap buffer
 overflows, out-of-memory faults, or segmentation faults that could be
 exploitable as denial-of-service attacks.
 
+### Image Size Limits and Out-of-Memory Failures
+
+The OpenEXR file format places no fixed limit on image size, except
+that image width and height are represented by signed 32-bit integers
+and therefore technically limited to a maximum of 2,147,483,647.
+
+Memory allocation failures caused by large image dimensions declared
+in file headers are not considered security vulnerabilities when the
+allocation size is proportional to the declared image dimensions. EXR
+files can legitimately describe very large images, and the memory
+required to decode them is inherently proportional to their pixel
+count. Exhausting available memory on a given machine is a system
+resource constraint, not a library defect — the same file that
+triggers an out-of-memory error on one machine may load successfully
+on another with more memory.
+
+The OpenEXR library provides 
+`Imf::Header::setMaxImageSize(int maxWidth,int maxHeight)` and
+`Imf::Header:"setMaxTileSize(int maxWidth,int maxHeight)` (and
+`exr_set_default_maximum_image_size()` and
+`exr_set_default_maximum_tile_size()` in OpenEXRCore) to allow
+applications to reject files with dimensions exceeding a configurable
+limit before any large allocation occurs. Applications processing
+untrusted EXR files should set these limits to values appropriate for
+their deployment environment.
+
 ### Hardening
 
 #### Testing

{openexr-3.4.8 → openexr-3.4.9}/cmake/LibraryDefine.cmake

@@ -96,8 +96,8 @@ function(OPENEXR_DEFINE_LIBRARY libname)
     set(verlibname ${CMAKE_SHARED_LIBRARY_PREFIX}${libname}${OPENEXR_LIB_SUFFIX}${CMAKE_${uppercase_CMAKE_BUILD_TYPE}_POSTFIX}${CMAKE_SHARED_LIBRARY_SUFFIX})
     set(baselibname ${CMAKE_SHARED_LIBRARY_PREFIX}${libname}${CMAKE_${uppercase_CMAKE_BUILD_TYPE}_POSTFIX}${CMAKE_SHARED_LIBRARY_SUFFIX})
     file(CREATE_LINK ${verlibname} ${CMAKE_CURRENT_BINARY_DIR}/${baselibname} SYMBOLIC)
-    install(FILES ${CMAKE_CURRENT_BINARY_DIR}/${baselibname} DESTINATION ${CMAKE_INSTALL_FULL_LIBDIR})
-    install(CODE "message(STATUS \"Creating symlink ${CMAKE_INSTALL_FULL_LIBDIR}/${baselibname} -> ${verlibname}\")")
+    install(FILES ${CMAKE_CURRENT_BINARY_DIR}/${baselibname} DESTINATION ${CMAKE_INSTALL_LIBDIR})
+    install(CODE "message(STATUS \"Creating symlink ${CMAKE_INSTALL_LIBDIR}/${baselibname} -> ${verlibname}\")")
     set(verlibname)
     set(baselibname)
   endif()

{openexr-3.4.8 → openexr-3.4.9}/src/lib/OpenEXRCore/internal_dwa_decoder.h

@@ -328,7 +328,7 @@ LossyDctDecoder_execute (
     rowBlock[0] = (uint16_t*) simd_align_pointer (rowBlockHandle);
 
     for (int comp = 1; comp < numComp; ++comp)
-        rowBlock[comp] = rowBlock[comp - 1] + numBlocksX * 64;
+        rowBlock[comp] = rowBlock[comp - 1] + (size_t) numBlocksX * 64;
 
     //
     // Pack DC components together by common plane, so we can get
@@ -338,7 +338,7 @@ LossyDctDecoder_execute (
 
     currDcComp[0] = (uint16_t*) d->_packedDc;
     for (int comp = 1; comp < numComp; ++comp)
-        currDcComp[comp] = currDcComp[comp - 1] + numBlocksX * numBlocksY;
+        currDcComp[comp] = currDcComp[comp - 1] + (size_t) numBlocksX * numBlocksY;
 
     for (int blocky = 0; blocky < numBlocksY; ++blocky)
     {
@@ -741,13 +741,22 @@ LossyDctDecoder_execute (
         /* process in place in reverse to avoid temporary buffer */
         for (int y = 0; y < d->_height; ++y)
         {
-            float*    floatXdrPtr = (float*) chanData[chan]->_rows[y];
-            uint16_t* halfXdr     = (uint16_t*) floatXdrPtr;
+            uint8_t* rowBytes = chanData[chan]->_rows[y];
 
             for (int x = d->_width - 1; x >= 0; --x)
             {
-                floatXdrPtr[x] = one_from_native_float (
-                    half_to_float (one_to_native16 (halfXdr[x])));
+                // TODO: make an unaligned_store32f that takes the float and
+                // packages up a one_from_native_float and calls memcpy
+                // instead of the two memcpy. We should look at the metrics
+                // for dwa and see if there's a performance difference to do
+                // so at some point. See:
+                // https://github.com/AcademySoftwareFoundation/openexr/pull/2324
+
+                uint16_t h = unaligned_load16 (rowBytes + x * sizeof (uint16_t));
+                float    f = half_to_float (h);
+                uint32_t bits;
+                memcpy (&bits, &f, sizeof (bits));
+                unaligned_store32 (rowBytes + x * sizeof (float), bits);
             }
         }
     }

{openexr-3.4.8 → openexr-3.4.9}/src/lib/OpenEXRCore/internal_piz.c

@@ -10,6 +10,7 @@
 #include "internal_huf.h"
 #include "internal_xdr.h"
 
+#include <limits.h>
 #include <string.h>
 
 /**************************************/
@@ -232,10 +233,11 @@ wdec16 (uint16_t l, uint16_t h, uint16_t* a, uint16_t* b)
 static void
 wav_2D_encode (uint16_t* in, int nx, int ox, int ny, int oy, uint16_t mx)
 {
-    int w14 = (mx < (1 << 14)) ? 1 : 0;
-    int n   = (nx > ny) ? ny : nx;
-    int p   = 1; // == 1 <<  level
-    int p2  = 2; // == 1 << (level+1)
+    int     w14  = (mx < (1 << 14)) ? 1 : 0;
+    int     n    = (nx > ny) ? ny : nx;
+    int     p    = 1; // == 1 <<  level
+    int     p2   = 2; // == 1 << (level+1)
+    int64_t oy64 = oy;
 
     //
     // Hierarchical loop on smaller dimension n
@@ -244,9 +246,9 @@ wav_2D_encode (uint16_t* in, int nx, int ox, int ny, int oy, uint16_t mx)
     while (p2 <= n)
     {
         uint16_t* py  = in;
-        uint16_t* ey  = in + oy * (ny - p2);
-        int       oy1 = oy * p;
-        int       oy2 = oy * p2;
+        uint16_t* ey  = in + oy64 * (ny - p2);
+        int64_t   oy1 = oy64 * p;
+        int64_t   oy2 = oy64 * p2;
         int       ox1 = ox * p;
         int       ox2 = ox * p2;
         uint16_t  i00, i01, i10, i11;
@@ -345,10 +347,11 @@ wav_2D_decode (
     int       oy, // i : y offset
     uint16_t  mx)  // i : maximum in[x][y] value
 {
-    int w14 = (mx < (1 << 14)) ? 1 : 0;
-    int n   = (nx > ny) ? ny : nx;
-    int p   = 1;
-    int p2;
+    int     w14  = (mx < (1 << 14)) ? 1 : 0;
+    int     n    = (nx > ny) ? ny : nx;
+    int     p    = 1;
+    int     p2;
+    int64_t oy64 = oy;
 
     //
     // Search max level
@@ -368,9 +371,9 @@ wav_2D_decode (
     while (p >= 1)
     {
         uint16_t* py  = in;
-        uint16_t* ey  = in + oy * (ny - p2);
-        int       oy1 = oy * p;
-        int       oy2 = oy * p2;
+        uint16_t* ey  = in + oy64 * (ny - p2);
+        int64_t   oy1 = oy64 * p;
+        int64_t   oy2 = oy64 * p2;
         int       ox1 = ox * p;
         int       ox2 = ox * p2;
         uint16_t  i00, i01, i10, i11;
@@ -566,11 +569,13 @@ internal_exr_apply_piz (exr_encode_pipeline_t* encode)
         nx     = curc->width;
         ny     = curc->height;
         wcount = (int) (curc->bytes_per_element / 2);
+        if (wcount > 0 && nx > INT_MAX / wcount)
+            return EXR_ERR_CORRUPT_CHUNK;
         for (int j = 0; j < wcount; ++j)
         {
             wav_2D_encode (wavbuf + j, nx, wcount, ny, wcount * nx, maxValue);
         }
-        wavbuf += nx * ny * wcount;
+        wavbuf += (uint64_t) nx * ny * wcount;
     }
 
     nBytes    = 0;
@@ -722,11 +727,13 @@ internal_exr_undo_piz (
         nx     = curc->width;
         ny     = curc->height;
         wcount = (int) (curc->bytes_per_element / 2);
+        if (wcount > 0 && nx > INT_MAX / wcount)
+            return EXR_ERR_CORRUPT_CHUNK;
         for (int j = 0; j < wcount; ++j)
         {
             wav_2D_decode (wavbuf + j, nx, wcount, ny, wcount * nx, maxValue);
         }
-        wavbuf += nx * ny * wcount;
+        wavbuf += (uint64_t) nx * ny * wcount;
     }
 
     //

{openexr-3.4.8 → openexr-3.4.9}/src/lib/OpenEXRCore/internal_pxr24.c

@@ -182,7 +182,7 @@ apply_pxr24_impl (exr_encode_pipeline_t* encode)
                     if (nOut + nBytes > encode->scratch_alloc_size_1)
                         return EXR_ERR_OUT_OF_MEMORY;
                     nOut += nBytes;
-                    lastIn += w * 4;
+                    lastIn += (uint64_t) w * 4;
 
                     ptr[0] = out;
                     out += w;
@@ -374,7 +374,7 @@ undo_pxr24_impl (
                     ptr[2] = lastIn;
                     lastIn += w;
 
-                    if (nDec + (uint64_t) (w * 3) > outSize)
+                    if (nDec + (uint64_t) w * 3 > outSize)
                         return EXR_ERR_CORRUPT_CHUNK;
 
                     for (int x = 0; x < w; ++x)
@@ -387,7 +387,7 @@ undo_pxr24_impl (
                         unaligned_store32 (dout, pixel);
                         ++dout;
                     }
-                    nDec += (uint64_t) (w * 3);
+                    nDec += (uint64_t) w * 3;
                     break;
                 }
                 default: return EXR_ERR_INVALID_ARGUMENT;

{openexr-3.4.8 → openexr-3.4.9}/src/lib/OpenEXRCore/openexr_version.h

@@ -10,6 +10,6 @@
 
 #    define OPENEXR_VERSION_MAJOR 3
 #    define OPENEXR_VERSION_MINOR 4
-#    define OPENEXR_VERSION_PATCH 8
+#    define OPENEXR_VERSION_PATCH 9
 
 #endif