#1133188 openexr: CVE-2026-34378 CVE-2026-34379 CVE-2026-34380 CVE-2026-34588 CVE-2026-34589 #1133188
- Package:
- src:openexr
- Source:
- src:openexr
- Submitter:
- Salvatore Bonaccorso
- Date:
- 2026-08-22 11:07:03 UTC
- Severity:
- normal
- Tags:
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
Sorry three CVEs, CVE-2026-3454{3,4,5} were already coverer by
#1132578, #1132579 and #1132580, so let's not track them here.
Regards,
Salvatore
Control: tags 1132578 + patch Control: tags 1132578 + pending Control: tags 1132579 + patch Control: tags 1132579 + pending Control: tags 1132580 + patch Control: tags 1132580 + pending Control: tags 1133188 + patch Control: tags 1133188 + pending Control: tags 1134642 + patch Control: tags 1134642 + pending Control: tags 1135946 + patch Control: tags 1135946 + pending Control: tags 1136001 + patch Control: tags 1136001 + pending Control: tags 1136879 + patch Control: tags 1136879 + pending Control: tags 1144763 + patch Control: tags 1144763 + pending Control: tags 1144878 + patch Control: tags 1144878 + pending Dear maintainer, I've prepared an NMU for openexr (versioned as 3.4.14-0.1) and uploaded it to DELAYED/2. Please feel free to tell me if I should cancel it. cu Adrian
Dear maintainer, I've prepared an NMU for openexr (versioned as 3.4.14-0.1) and uploaded it to DELAYED/1. Please feel free to tell me if I should cancel it. Two changes compared to the previous version: - list more CVEs in the changelog - forwarded a patch upstream cu Adrian
We believe that the bug you reported is fixed in the latest version of
openexr, which is due to be installed in the Debian FTP archive.
A summary of the changes between this version and the previous one is
attached.
Thank you for reporting the bug, which will now be closed. If you
have further comments please address them to 1133188@bugs.debian.org,
and the maintainer will reopen the bug report if appropriate.
Debian distribution maintenance software
pp.
Adrian Bunk <bunk@debian.org> (supplier of updated openexr package)
(This message was generated automatically at their request; if you
believe that there is a problem with it please contact the archive
administrators by mailing ftpmaster@ftp-master.debian.org)
Format: 1.8
Date: Thu, 20 Aug 2026 19:49:50 +0300
Source: openexr
Architecture: source
Version: 3.4.14-0.1
Distribution: unstable
Urgency: medium
Maintainer: Debian PhotoTools Maintainers <pkg-phototools-devel@lists.alioth.debian.org>
Changed-By: Adrian Bunk <bunk@debian.org>
Closes: 1132578 1132579 1132580 1133188 1134642 1135946 1136001 1136879 1144763 1144878
Changes:
openexr (3.4.14-0.1) unstable; urgency=medium
.
* Non-maintainer upload.
* New upstream release. (Closes: #1136879)
- Fixes FTBFS with glibc 2.43. (Closes: #1144878)
- CVE-2026-34378: Signed integer overflow in generic_unpack()
- CVE-2026-34379: Misaligned write in LossyDctDecoder_execute
- CVE-2026-34380: Signed integer overflow in undo_pxr24_impl()
- CVE-2026-34588: Signed 32-bit Overflow in PIZ Decoder
- CVE-2026-34589: DWA Lossy Decoder Heap Out-of-Bounds Write
(Closes: #1133188)
- CVE-2026-34543: Heap information disclosure in PXR24 decompression
(Closes: #1132580)
- CVE-2026-34544: Integer overflow in uncompress_b44_impl()
(Closes: #1132579)
- CVE-2026-34545: Integer overflow in HTJ2K decoder
(Closes: #1132578)
- CVE-2026-39886: Signed Integer Overflow in ht_undo_impl()
- CVE-2026-40244: Integer overflow in DWA setupChannelData
- CVE-2026-40250: Integer overflow in DWA decoder
(Closes: #1134642)
- CVE-2026-41142: Integer overflow in ImageChannel::resize()
(Closes: #1135946)
- CVE-2026-42216: Out-of-bounds read in IDManifest::init()
- CVE-2026-42217: Shift exponent overflow in readVariableLengthInteger()
(Closes: #1136001)
- CVE-2026-44663: Integer overflow in HTJ2K decoder
- CVE-2026-45696: Heap buffer overflow in ht_undo_impl()
- CVE-2026-59183: Signed Integer Overflow in Deep Tile Decoding
- CVE-2026-59184: OpenEXRUtil FlatImageChannel row OOB write
- CVE-2026-59186: OpenEXR ILP32 TiledRgbaInputFile large tile OOB write
- CVE-2026-59187: OpenEXR exrmetrics deep pixelmode heap buffer overflow
- CVE-2026-59189: OpenEXRUtil DeepImageChannel heap OOB read
- CVE-2026-59981: OpenEXRUtil SampleCountChannel heap OOB read
- CVE-2026-59982: ILP32 DWAA InputFile packed AC buffer overflow
- CVE-2026-59983: ILP32 DeepTiledInputFile sample count table OOB read
- CVE-2026-59984: ILP32 B44 InputFile decode scratch buffer overflow
- CVE-2026-59985: ILP32 OpenEXRCore RLE decode heap OOB read DoS
- CVE-2026-61555: Empty multiView viewFromChannelName file crash
* Generate Provides that includes the Imath version and use in the shlibs.
(Closes: #1144763)
* Disable test that fails on armhf instead of ignoring all test failures
on armhf.
* Ignore test failures on all big endian architectures.
* Attempt to fix FTBFS on hurd-amd64.
* Ignore test failures on Hurd.
Checksums-Sha1:
4e1228f642baa3d056345996075470e88150a253 2261 openexr_3.4.14-0.1.dsc
c0bb14f1dfb0c9a6f2e38725397013ce9ce4d6b8 20598272 openexr_3.4.14.orig.tar.xz
674d0668a9d7ed5619bb34670cab2513dbd573cd 19384 openexr_3.4.14-0.1.debian.tar.xz
Checksums-Sha256:
30540eb3d46620be9aaed388d0c179d5846a890e94baf48e0f1650ca3cd4d7a7 2261 openexr_3.4.14-0.1.dsc
5bc1a561a418ac59b5c309e42820dda0e6f4c087f10b5cf8e30c4899c1d68f09 20598272 openexr_3.4.14.orig.tar.xz
d1f1929c2045562640f5c3cda3ef93ca49827e2ad91ae90fde243bd16a0aeeef 19384 openexr_3.4.14-0.1.debian.tar.xz
Files:
9d9256429c816c2e26a22ad778d85ed9 2261 graphics optional openexr_3.4.14-0.1.dsc
64216513dde4a579c60354b610bb4d6e 20598272 graphics optional openexr_3.4.14.orig.tar.xz
e3937bbb7954bbf50ee6716787358e25 19384 graphics optional openexr_3.4.14-0.1.debian.tar.xz
-----BEGIN PGP SIGNATURE-----
iQIzBAEBCgAdFiEEOvp1f6xuoR0v9F3wiNJCh6LYmLEFAmqIN2YACgkQiNJCh6LY
mLF8Wg//dkxGb0fDrFTms4t1AGU/RCsBLVseTT/5Uj19NA2QmRW0YmKTWDqXZocR
RtuvI68uXEfaQkyiqPu2NGN7vrKls/uRJWmzTHUSVl8/ZteRX1cV8gV7mNcVS2m2
8y3/QStwtI01hic95HJLSzowvj+Jf8vlwp/zehkS7fluzbdgrDJJ1vlhGuo29toO
mVNdxXXPGbXzL7ZiP6VsZERwwFcXoI0Z5I/79DzWECuksASnAepAK6G58IXR9On5
JPEvXnbSVGkOLupvXUnb+rDXjOGQaYaBwZdK1by2NMjXTFOHEv7iiZPJ8WG9jegv
mfC5ckP2trlpl3i7kn4wU6cpVprXF9mqcWrpcpdsylEUouNugyKhaExILqxu9/Sh
vXH7kmz88OckgvAUzJsjk8A4mt+BcW5KTXjufHUYf6sS+lfHMOBAH9NZ/yikLR40
J+TNd/q49Wgfdy6l5OCgYB+1py/ub7H+R8r3UGhUlqPjgnrVbKengIpxE+gBUFJf
bZz1OOQpP5D6tkK02B9XEC9rS0eY+8RTt+BkML+r02IoPoanbILOPl8h4KhSptC6
g84K0C5bp5Od9/szAENqXaWaRWjd71y9oULX4n/SYlQkD4co2VhAya7fGxl8zb/Q
FavZbrG3lhwRPOfupiNstpSJwkBYdC0/+3GVkV93Oi753mtEElU=
=5zjm
-----END PGP SIGNATURE-----