Bug#1133188: openexr: CVE-2026-34378 CVE-2026-34379 CVE-2026-34380 CVE-2026-34543 CVE-2026-34544 CVE-2026-34545 CVE-2026-34588 CVE-2026-34589

[Salvatore Bonaccorso]

Source: openexr
Version: 3.4.6+ds-4
Severity: important
Tags: security upstream
X-Debbugs-Cc: carnil at debian.org, Debian Security Team <team at security.debian.org>

Hi,

The following vulnerabilities were published for openexr.

CVE-2026-34378[0]:
| OpenEXR provides the specification and reference implementation of
| the EXR file format, an image storage format for the motion picture
| industry. From 3.4.0 to before 3.4.9, a missing bounds check on the
| dataWindow attribute in EXR file headers allows an attacker to
| trigger a signed integer overflow in generic_unpack(). By setting
| dataWindow.min.x to a large negative value, OpenEXRCore computes an
| enormous image width, which is later used in a signed integer
| multiplication that overflows, causing the process to terminate with
| SIGILL via UBSan. This vulnerability is fixed in 3.4.9.


CVE-2026-34379[1]:
| OpenEXR provides the specification and reference implementation of
| the EXR file format, an image storage format for the motion picture
| industry. From 3.2.0 to before 3.2.7, 3.3.9, and 3.4.9, a misaligned
| memory write vulnerability exists in LossyDctDecoder_execute() in
| src/lib/OpenEXRCore/internal_dwa_decoder.h:749. When decoding a DWA
| or DWAB-compressed EXR file containing a FLOAT-type channel, the
| decoder performs an in-place HALF→FLOAT conversion by casting an
| unaligned uint8_t * row pointer to float * and writing through it.
| Because the row buffer may not be 4-byte aligned, this constitutes
| undefined behavior under the C standard and crashes immediately on
| architectures that enforce alignment (ARM, RISC-V, etc.). On x86 it
| is silently tolerated at runtime but remains exploitable via
| compiler optimizations that assume aligned access. This
| vulnerability is fixed in 3.2.7, 3.3.9, and 3.4.9.


CVE-2026-34380[2]:
| OpenEXR provides the specification and reference implementation of
| the EXR file format, an image storage format for the motion picture
| industry. From 3.2.0 to before 3.2.7, 3.3.9, and 3.4.9, a signed
| integer overflow exists in undo_pxr24_impl() in
| src/lib/OpenEXRCore/internal_pxr24.c at line 377. The expression
| (uint64_t)(w * 3) computes w * 3 as a signed 32-bit integer before
| casting to uint64_t. When w is large, this multiplication
| constitutes undefined behavior under the C standard. On tested
| builds (clang/gcc without sanitizers), two's-complement wraparound
| commonly occurs, and for specific values of w the wrapped result is
| a small positive integer, which may allow the subsequent bounds
| check to pass incorrectly. If the check is bypassed, the decoding
| loop proceeds to write pixel data through dout, potentially
| extending far beyond the allocated output buffer. This vulnerability
| is fixed in 3.2.7, 3.3.9, and 3.4.9.


CVE-2026-34543[3]:
| OpenEXR provides the specification and reference implementation of
| the EXR file format, an image storage format for the motion picture
| industry. From version 3.4.0 to before version 3.4.8, sensitive
| information from heap memory may be leaked through the decoded pixel
| data (information disclosure). This occurs under default settings;
| simply reading a malicious EXR file is sufficient to trigger the
| issue, without any user interaction. This issue has been patched in
| version 3.4.8.


CVE-2026-34544[4]:
| OpenEXR provides the specification and reference implementation of
| the EXR file format, an image storage format for the motion picture
| industry. From version 3.4.0 to before version 3.4.8, a crafted B44
| or B44A EXR file can cause an out-of-bounds write in any application
| that decodes it via exr_decoding_run(). Consequences range from
| immediate crash (most likely) to corruption of adjacent heap
| allocations (layout-dependent). This issue has been patched in
| version 3.4.8.


CVE-2026-34545[5]:
| OpenEXR provides the specification and reference implementation of
| the EXR file format, an image storage format for the motion picture
| industry. From version 3.4.0 to before version 3.4.7, an attacker
| providing a crafted .exr file with HTJ2K compression and a channel
| width of 32768 can write controlled data beyond the output heap
| buffer in any application that decodes EXR images. The write
| primitive is 2 bytes per overflow iteration or 4 bytes (by another
| path), repeating for each additional pixel past the overflow point.
| In this context, a heap write overflow can lead to remote code
| execution on systems. This issue has been patched in version 3.4.7.


CVE-2026-34588[6]:
| OpenEXR provides the specification and reference implementation of
| the EXR file format, an image storage format for the motion picture
| industry. From 3.1.0 to before 3.2.7, 3.3.9, and 3.4.9,
| internal_exr_undo_piz() advances the working wavelet pointer with
| signed 32-bit arithmetic. Because nx, ny, and wcount are int, a
| crafted EXR file can make this product overflow and wrap. The next
| channel then decodes from an incorrect address. The wavelet decode
| path operates in place, so this yields both out-of-bounds reads and
| out-of-bounds writes. This vulnerability is fixed in 3.2.7, 3.3.9,
| and 3.4.9.


CVE-2026-34589[7]:
| OpenEXR provides the specification and reference implementation of
| the EXR file format, an image storage format for the motion picture
| industry. From 3.2.0 to before 3.2.7, 3.3.9, and 3.4.9, the DWA
| lossy decoder constructs temporary per-component block pointers
| using signed 32-bit arithmetic. For a large enough width, the
| calculation overflows and later decoder stores operate on a wrapped
| pointer outside the allocated rowBlock backing store. This
| vulnerability is fixed in 3.2.7, 3.3.9, and 3.4.9.


If you fix the vulnerabilities please also make sure to include the
CVE (Common Vulnerabilities & Exposures) ids in your changelog entry.

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2026-34378
    https://www.cve.org/CVERecord?id=CVE-2026-34378
[1] https://security-tracker.debian.org/tracker/CVE-2026-34379
    https://www.cve.org/CVERecord?id=CVE-2026-34379
[2] https://security-tracker.debian.org/tracker/CVE-2026-34380
    https://www.cve.org/CVERecord?id=CVE-2026-34380
[3] https://security-tracker.debian.org/tracker/CVE-2026-34543
    https://www.cve.org/CVERecord?id=CVE-2026-34543
[4] https://security-tracker.debian.org/tracker/CVE-2026-34544
    https://www.cve.org/CVERecord?id=CVE-2026-34544
[5] https://security-tracker.debian.org/tracker/CVE-2026-34545
    https://www.cve.org/CVERecord?id=CVE-2026-34545
[6] https://security-tracker.debian.org/tracker/CVE-2026-34588
    https://www.cve.org/CVERecord?id=CVE-2026-34588
[7] https://security-tracker.debian.org/tracker/CVE-2026-34589
    https://www.cve.org/CVERecord?id=CVE-2026-34589

Regards,
Salvatore