{"id":"CVE-2026-34589","aliases":["ALPINE-CVE-2026-34589","BELL-CVE-2026-34589","DEBIAN-CVE-2026-34589","EUVD-2026-19348","GHSA-p8xc-w3q4-h64x","JLSEC-2026-149","OESA-2026-1840","OESA-2026-1841","OESA-2026-1842","OESA-2026-1843","OESA-2026-1844","PYSEC-2026-2848","ROOT-OS-DEBIAN-11-CVE-2026-34589","ROOT-OS-DEBIAN-12-CVE-2026-34589","ROOT-OS-DEBIAN-13-CVE-2026-34589","SUSE-SU-2026:21372-1","UBUNTU-CVE-2026-34589","openSUSE-SU-2026:10505-1","openSUSE-SU-2026:20605-1"],"status":"published","title":"OpenEXR: DWA Lossy Decoder Heap Out-of-Bounds Write","description":"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.","severity":{"version":"4.0","score":8.4,"vector":"CVSS:4.0/AV:L/AC:L/AT:N/PR:N/UI:A/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N","level":"high","assessor":"cna","from":"cve"},"epss":{"day":"2026-11-10","score":0.00426,"percentile":0.37214,"model":"v2026.06.15"},"facts":{"in_kev":false,"known_exploited":false,"public_exploit":false,"fix_available":true},"cwes":["CWE-190","CWE-787"],"published":"2026-04-06T15:33:03Z","modified":"2026-11-03T06:32:55Z","fixes":[{"ecosystem":"PyPI","package":"openexr","fixed_in":["3.2.7","3.3.9","3.4.9"],"sources":["ghsa","osv"]},{"ecosystem":"Alpine:v3.22","package":"openexr","fixed_in":["3.3.11-r0"],"sources":["osv"]},{"ecosystem":"Alpine:v3.23","package":"openexr","fixed_in":["3.4.13-r0"],"sources":["osv"]},{"ecosystem":"Alpine:v3.24","package":"openexr","fixed_in":["3.4.10-r0"],"sources":["osv"]},{"ecosystem":"Alpaquita:stream","package":"openexr","fixed_in":["3.4.9-r0"],"sources":["osv"]},{"ecosystem":"Debian:14","package":"openexr","fixed_in":["3.4.14-0.1"],"sources":["osv"]},{"ecosystem":"Julia","package":"OpenEXR_jll","fixed_in":["3.4.9+0"],"sources":["osv"]},{"ecosystem":"Root:Debian:11","package":"openexr","fixed_in":["2.5.4-2+deb11u1.aikido.17","2.5.4-2+deb11u1.aikido.16","2.5.4-2+deb11u1.root.io.15","2.5.4-2+deb11u1.aikido.18"],"sources":["osv"]},{"ecosystem":"Root:Debian:11","package":"rootio-openexr","fixed_in":["2.5.4-2+deb11u1.aikido.17","2.5.4-2+deb11u1.aikido.16","2.5.4-2+deb11u1.root.io.15","2.5.4-2+deb11u1.aikido.18"],"sources":["osv"]},{"ecosystem":"Root:Debian:12","package":"openexr","fixed_in":["3.1.5-5.root.io.21","3.1.5-5.root.io.22","3.1.5-5.root.io.23","3.1.5-5.root.io.16","3.1.5-5.root.io.17","3.1.5-5.root.io.18","3.1.5-5.root.io.19","3.1.5-5.root.io.20","3.1.5-5.aikido.24","3.1.5-5.aikido.25"],"sources":["osv"]},{"ecosystem":"Root:Debian:12","package":"rootio-openexr","fixed_in":["3.1.5-5.root.io.21","3.1.5-5.root.io.22","3.1.5-5.root.io.23","3.1.5-5.root.io.16","3.1.5-5.root.io.17","3.1.5-5.root.io.18","3.1.5-5.root.io.19","3.1.5-5.root.io.20","3.1.5-5.aikido.24","3.1.5-5.aikido.25"],"sources":["osv"]},{"ecosystem":"Root:Debian:13","package":"openexr","fixed_in":["3.1.13-2.aikido.14","3.1.13-2.root.io.11","3.1.13-2.root.io.13","3.1.13-2.root.io.12","3.1.13-2.aikido.15"],"sources":["osv"]},{"ecosystem":"Root:Debian:13","package":"rootio-openexr","fixed_in":["3.1.13-2.aikido.14","3.1.13-2.root.io.11","3.1.13-2.root.io.13","3.1.13-2.root.io.12","3.1.13-2.aikido.15"],"sources":["osv"]}],"affected":[{"source":"ghsa","ecosystem":"PyPI","package":"openexr","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"3.2.0"},{"fixed":"3.2.7"}]}]},{"source":"ghsa","ecosystem":"PyPI","package":"openexr","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"3.3.0"},{"fixed":"3.3.9"}]}]},{"source":"ghsa","ecosystem":"PyPI","package":"openexr","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"3.4.0"},{"fixed":"3.4.9"}]}]},{"source":"osv","ecosystem":"Alpine:v3.22","package":"openexr","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"3.2.0"},{"fixed":"3.3.11-r0"}]}]},{"source":"osv","ecosystem":"Alpine:v3.23","package":"openexr","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"3.2.0"},{"fixed":"3.4.13-r0"}]}]},{"source":"osv","ecosystem":"Alpine:v3.24","package":"openexr","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"3.2.0"},{"fixed":"3.4.10-r0"}]}]},{"source":"osv","ecosystem":"Alpaquita:stream","package":"openexr","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"3.4.4-r0"},{"fixed":"3.4.9-r0"}]}]},{"source":"osv","ecosystem":"Debian:12","package":"openexr","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"}]}],"versions":["3.1.13-1","3.1.13-2","3.1.5-5","3.1.5-5.1","3.1.5-5.1+hurd.1","3.4.14-0.1","3.4.15+ds-1","3.4.16+ds-1","3.4.6+ds-1","3.4.6+ds-2","3.4.6+ds-3","3.4.6+ds-4","3.5.2+ds-1"]},{"source":"osv","ecosystem":"Debian:13","package":"openexr","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"}]}],"versions":["3.1.13-2","3.4.14-0.1","3.4.15+ds-1","3.4.16+ds-1","3.4.6+ds-1","3.4.6+ds-2","3.4.6+ds-3","3.4.6+ds-4","3.5.2+ds-1"]},{"source":"osv","ecosystem":"Debian:14","package":"openexr","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"3.4.14-0.1"}]}],"versions":["3.1.13-2","3.4.6+ds-1","3.4.6+ds-2","3.4.6+ds-3","3.4.6+ds-4"]},{"source":"osv","ecosystem":"PyPI","package":"openexr","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"3.2.0"},{"fixed":"3.2.7"}]}],"versions":["3.2.3","3.2.4","3.2.5","3.2.6"]},{"source":"osv","ecosystem":"PyPI","package":"openexr","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"3.3.0"},{"fixed":"3.3.9"}]}],"versions":["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.3.8"]},{"source":"osv","ecosystem":"PyPI","package":"openexr","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"3.4.0"},{"fixed":"3.4.9"}]}],"versions":["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"]},{"source":"osv","ecosystem":"Julia","package":"OpenEXR_jll","ranges":[{"type":"SEMVER","events":[{"introduced":"3.1.4+0"},{"fixed":"3.4.9+0"}]}]},{"source":"osv","ecosystem":"openEuler:24.03-LTS","package":"OpenEXR","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"3.1.11-7.oe2403"}]}],"bundled":4},{"source":"osv","ecosystem":"openEuler:24.03-LTS-SP1","package":"OpenEXR","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"3.1.11-7.oe2403sp1"}]}],"bundled":4},{"source":"osv","ecosystem":"openEuler:24.03-LTS-SP2","package":"OpenEXR","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"3.1.11-7.oe2403sp2"}]}],"bundled":4},{"source":"osv","ecosystem":"openEuler:24.03-LTS-SP3","package":"OpenEXR","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"3.1.11-7.oe2403sp3"}]}],"bundled":4},{"source":"osv","ecosystem":"openEuler:22.03-LTS-SP4","package":"OpenEXR","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"3.1.5-6.oe2203sp4"}]}],"bundled":2},{"source":"osv","ecosystem":"PyPI","package":"openexr","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"3.2.0"},{"fixed":"3.2.7"},{"introduced":"3.3.0"},{"fixed":"3.3.9"},{"introduced":"3.4.0"},{"fixed":"3.4.9"}]}],"versions":["3.2.3","3.2.4","3.2.5","3.2.6","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.3.8","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"]},{"source":"osv","ecosystem":"Root:Debian:11","package":"openexr","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"2.5.4-2+deb11u1.aikido.17"},{"fixed":"2.5.4-2+deb11u1.aikido.16"},{"fixed":"2.5.4-2+deb11u1.root.io.15"},{"fixed":"2.5.4-2+deb11u1.aikido.18"}]}]},{"source":"osv","ecosystem":"Root:Debian:11","package":"rootio-openexr","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"2.5.4-2+deb11u1.aikido.17"},{"fixed":"2.5.4-2+deb11u1.aikido.16"},{"fixed":"2.5.4-2+deb11u1.root.io.15"},{"fixed":"2.5.4-2+deb11u1.aikido.18"}]}]},{"source":"osv","ecosystem":"Root:Debian:12","package":"openexr","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"3.1.5-5.root.io.21"},{"fixed":"3.1.5-5.root.io.22"},{"fixed":"3.1.5-5.root.io.23"},{"fixed":"3.1.5-5.root.io.16"},{"fixed":"3.1.5-5.root.io.17"},{"fixed":"3.1.5-5.root.io.18"},{"fixed":"3.1.5-5.root.io.19"},{"fixed":"3.1.5-5.root.io.20"},{"fixed":"3.1.5-5.aikido.24"},{"fixed":"3.1.5-5.aikido.25"}]}]},{"source":"osv","ecosystem":"Root:Debian:12","package":"rootio-openexr","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"3.1.5-5.root.io.21"},{"fixed":"3.1.5-5.root.io.22"},{"fixed":"3.1.5-5.root.io.23"},{"fixed":"3.1.5-5.root.io.16"},{"fixed":"3.1.5-5.root.io.17"},{"fixed":"3.1.5-5.root.io.18"},{"fixed":"3.1.5-5.root.io.19"},{"fixed":"3.1.5-5.root.io.20"},{"fixed":"3.1.5-5.aikido.24"},{"fixed":"3.1.5-5.aikido.25"}]}]},{"source":"osv","ecosystem":"Root:Debian:13","package":"openexr","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"3.1.13-2.aikido.14"},{"fixed":"3.1.13-2.root.io.11"},{"fixed":"3.1.13-2.root.io.13"},{"fixed":"3.1.13-2.root.io.12"},{"fixed":"3.1.13-2.aikido.15"}]}]},{"source":"osv","ecosystem":"Root:Debian:13","package":"rootio-openexr","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"3.1.13-2.aikido.14"},{"fixed":"3.1.13-2.root.io.11"},{"fixed":"3.1.13-2.root.io.13"},{"fixed":"3.1.13-2.root.io.12"},{"fixed":"3.1.13-2.aikido.15"}]}]},{"source":"osv","ecosystem":"Ubuntu:26.10","package":"openexr","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"}]}],"versions":["3.1.13-2build1","3.4.6+ds-4ubuntu3"]},{"source":"osv","ecosystem":"openSUSE:Tumbleweed","package":"openexr","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"3.4.9-1.1"}]}],"bundled":8},{"source":"osv","ecosystem":"openSUSE:Leap 16.0","package":"openexr","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"3.2.2-160000.6.1"}]}],"bundled":4}],"products":[{"vendor":"academysoftwarefoundation","product":"openexr"},{"vendor":"openexr","product":"openexr"},{"vendor":"red hat","product":"red hat enterprise linux 10"},{"vendor":"red hat","product":"red hat enterprise linux 6"},{"vendor":"red hat","product":"red hat enterprise linux 7"},{"vendor":"red hat","product":"red hat enterprise linux 8"},{"vendor":"red hat","product":"red hat enterprise linux 9"}],"references":[{"url":"https://github.com/AcademySoftwareFoundation/openexr/security/advisories/GHSA-p8xc-w3q4-h64x","tags":["x_refsource_CONFIRM","Exploit","Vendor Advisory","advisory","web","report"]},{"url":"https://github.com/AcademySoftwareFoundation/openexr/releases/tag/v3.2.7","tags":["x_refsource_MISC","Product","Release Notes","web","report"]},{"url":"https://github.com/AcademySoftwareFoundation/openexr/releases/tag/v3.3.9","tags":["x_refsource_MISC","Product","Release Notes","web","report"]},{"url":"https://github.com/AcademySoftwareFoundation/openexr/releases/tag/v3.4.9","tags":["x_refsource_MISC","Product","Release Notes","web","report"]},{"url":"https://access.redhat.com/security/cve/CVE-2026-34589","tags":["vdb-entry","x_refsource_REDHAT","advisory","web"]},{"url":"https://bugzilla.redhat.com/show_bug.cgi?id=2455411","tags":["issue-tracking","x_refsource_REDHAT","report","web"]},{"url":"https://security.access.redhat.com/data/csaf/v2/vex/2026/cve-2026-34589.json","tags":["x_sadp-csaf-vex","web"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2026-34589","tags":["advisory"]},{"url":"https://github.com/advisories/GHSA-p8xc-w3q4-h64x","tags":["advisory"]},{"url":"https://security.alpinelinux.org/vuln/CVE-2026-34589","tags":["advisory"]},{"url":"https://docs.bell-sw.com/security/cves/CVE-2026-34589","tags":["advisory"]},{"url":"https://github.com/CVEProject/cvelistV5/tree/main/cves/2026/34xxx/CVE-2026-34589.json","tags":["advisory"]},{"url":"https://security-tracker.debian.org/tracker/CVE-2026-34589","tags":["advisory"]},{"url":"https://github.com/AcademySoftwareFoundation/openexr","tags":["package"]},{"url":"https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2026-1840","tags":["advisory"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2026-34379","tags":["advisory"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2026-34380","tags":["advisory"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2026-34588","tags":["advisory"]},{"url":"https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2026-1841","tags":["advisory"]},{"url":"https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2026-1842","tags":["advisory"]},{"url":"https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2026-1843","tags":["advisory"]},{"url":"https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2026-1844","tags":["advisory"]},{"url":"https://pypi.org/project/openexr","tags":["package"]},{"url":"https://www.suse.com/support/update/announcement/2026/suse-su-202621372-1/","tags":["advisory"]},{"url":"https://bugzilla.suse.com/1261621","tags":["report"]},{"url":"https://bugzilla.suse.com/1261622","tags":["report"]},{"url":"https://bugzilla.suse.com/1261624","tags":["report"]},{"url":"https://bugzilla.suse.com/1261634","tags":["report"]},{"url":"https://www.suse.com/security/cve/CVE-2026-34379","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-34380","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-34588","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-34589","tags":["web"]},{"url":"https://ubuntu.com/security/CVE-2026-34589","tags":["report"]},{"url":"https://www.cve.org/CVERecord?id=CVE-2026-34589","tags":["report"]},{"url":"https://github.com/AcademySoftwareFoundation/openexr/pull/2329","tags":["report"]},{"url":"https://github.com/AcademySoftwareFoundation/openexr/commit/7c31424f9e381f386af83194d0b0e253da4a24d2","tags":["report"]},{"url":"https://github.com/AcademySoftwareFoundation/openexr/commit/9ad6c97548a54fea8d2fdc1a06883bbba7c5c9c3","tags":["report"]},{"url":"https://github.com/AcademySoftwareFoundation/openexr/commit/a76a8e0d1a180089658498c015d9809687a3ebfd","tags":["report"]},{"url":"","tags":["advisory"]},{"url":"https://www.suse.com/security/cve/CVE-2026-34378","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-34543","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-34544","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-34545","tags":["web"]}],"sources":{"cve":[{"id":"CVE-2026-34589","title":"OpenEXR: DWA Lossy Decoder Heap Out-of-Bounds Write","description":"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.","status":"published","published":"2026-04-06T15:33:03.276Z","modified":"2026-07-15T01:04:11.57Z","cvss":[{"version":"4.0","score":8.4,"vector":"CVSS:4.0/AV:L/AC:L/AT:N/PR:N/UI:A/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N","level":"high","assessor":"cna"},{"version":"3.1","score":8.8,"vector":"CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H","level":"high","assessor":"adp"}],"cwes":["CWE-190","CWE-787","CWE-190"],"updated_at":"2026-11-02T14:20:13.962274Z"}],"euvd":[{"id":"EUVD-2026-19348","description":"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.","status":"published","published":"2026-04-06T15:33:03Z","modified":"2026-07-15T01:04:11Z","cvss":[{"version":"4.0","score":8.4,"vector":"CVSS:4.0/AV:L/AC:L/AT:N/PR:N/UI:A/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N","level":"high"}],"updated_at":"2026-11-02T18:19:56.47701Z"}],"ghsa":[{"id":"GHSA-p8xc-w3q4-h64x","title":"OpenEXR: DWA Lossy Decoder Heap Out-of-Bounds Write","description":"## Summary\n\nThe 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.\n\nThis bug is reachable from the public decoder path and can be reproduced through the shipped `exrcheck` tool with a crafted scanline DWAA file. The confirmed dynamic symptom is a write-side crash in the lossy DCT execution path.\n\nTested on commit: 7820b7e1b93405ba1d551c43a945018226b75bc5\n\n## Root Cause and Data Flow\n\nThe vulnerable pointer construction lives in `src/lib/OpenEXRCore/internal_dwa_decoder.h`:\n\n```c\nfor (int comp = 1; comp \u003c numComp; ++comp)\n    rowBlock[comp] = rowBlock[comp - 1] + numBlocksX * 64;\n```\n\nThe expression `numBlocksX * 64` is computed as signed `int`. Once `numBlocksX` is large enough, the multiplication wraps, and `rowBlock[comp]` points backward rather than forward into the temporary decode buffer.\n\nLater, `LossyDctDecoder_execute()` uses those derived pointers for real loads and stores during the block shuffle and reconstruction process. At that point the decoder is no longer operating within the bounds of the allocation created for `rowBlockHandle`.\n\nThe public control flow is the standard one:\n\n```c\nInputFile / ScanLineInputFile public read\n  -\u003e exr_decoding_run(...)\n     -\u003e exr_uncompress_chunk(...)\n        -\u003e internal_exr_undo_dwaa(...)\n           -\u003e DwaCompressor_uncompress(...)\n              -\u003e LossyDctDecoder_execute(...)\n```\n\nUBSan gives a clean root-cause diagnosis on the overflowing multiply, while ASAN shows the later memory error in the write-side decode path.\n\n## Reproduction\n\n[dwa_scanline_exrcheck.zip](https://github.com/user-attachments/files/26318786/dwa_scanline_exrcheck.zip)\n\nBuild with `exrcheck` with ASAN and run:\n\n```\n❯ ./build-asan/bin/exrcheck /tmp/dwa_scanline_exrcheck.exr\n file /tmp/dwa_scanline_exrcheck.exr /home/pop/sec/openexr/src/lib/OpenEXRCore/internal_dwa_decoder.h:331:58: runtime error: signed integer overflow: 33554432 * 64 cannot be represented in type 'int'\nAddressSanitizer:DEADLYSIGNAL\n=================================================================\n==1684058==ERROR: AddressSanitizer: SEGV on unknown address 0x758f8e5f0800 (pc 0x75979e850336 bp 0x7ffe8f1d3420 sp 0x7ffe8f1d30f0 T0)\n==1684058==The signal is caused by a WRITE memory access.\n    #0 0x75979e850336 in LossyDctDecoder_execute /home/pop/sec/openexr/src/lib/OpenEXRCore/internal_dwa_decoder.h:524\n    #1 0x75979e879592 in DwaCompressor_uncompress /home/pop/sec/openexr/src/lib/OpenEXRCore/internal_dwa_compressor.h:1210\n    #2 0x75979e879592 in internal_exr_undo_dwaa /home/pop/sec/openexr/src/lib/OpenEXRCore/internal_dwa.c:231\n    #3 0x75979e95f878 in exr_uncompress_chunk /home/pop/sec/openexr/src/lib/OpenEXRCore/compression.c:542\n    #4 0x75979e9659a8 in exr_decoding_run /home/pop/sec/openexr/src/lib/OpenEXRCore/decoding.c:580\n    #5 0x7597a0271add in run_decode /home/pop/sec/openexr/src/lib/OpenEXR/ImfScanLineInputFile.cpp:586\n    #6 0x7597a0283dc4 in Imf_4_0::ScanLineInputFile::Data::readPixels(Imf_4_0::FrameBuffer const\u0026, int, int) /home/pop/sec/openexr/src/lib/OpenEXR/ImfScanLineInputFile.cpp:500\n    #7 0x7597a00c6a81 in Imf_4_0::InputFile::Data::readPixels(int, int) /home/pop/sec/openexr/src/lib/OpenEXR/ImfInputFile.cpp:458\n    #8 0x7597a13fe2dc in readScanline\u003cImf_4_0::InputPart\u003e /home/pop/sec/openexr/src/lib/OpenEXRUtil/ImfCheckFile.cpp:239\n    #9 0x7597a1405b04 in readMultiPart /home/pop/sec/openexr/src/lib/OpenEXRUtil/ImfCheckFile.cpp:905\n    #10 0x7597a14126fd in runChecks\u003cchar const*\u003e /home/pop/sec/openexr/src/lib/OpenEXRUtil/ImfCheckFile.cpp:1171\n    #11 0x7597a14146b9 in Imf_4_0::checkOpenEXRFile(char const*, bool, bool, bool) /home/pop/sec/openexr/src/lib/OpenEXRUtil/ImfCheckFile.cpp:1835\n    #12 0x61ba9582b8f8 in exrCheck(char const*, bool, bool, bool, bool) /home/pop/sec/openexr/src/bin/exrcheck/main.cpp:96\n    #13 0x61ba958282b1 in main /home/pop/sec/openexr/src/bin/exrcheck/main.cpp:164\n    #14 0x75979d62a1c9 in __libc_start_call_main ../sysdeps/nptl/libc_start_call_main.h:58\n    #15 0x75979d62a28a in __libc_start_main_impl ../csu/libc-start.c:360\n    #16 0x61ba95829844 in _start (/home/pop/sec/openexr/build-asan/bin/exrcheck+0xe844) (BuildId: 087c972343a5372940c42c0a2e7bce4a84288aec)\n\nAddressSanitizer can not provide additional info.\nSUMMARY: AddressSanitizer: SEGV /home/pop/sec/openexr/src/lib/OpenEXRCore/internal_dwa_decoder.h:524 in LossyDctDecoder_execute\n==1684058==ABORTING\n```\n-------\nFound by: Quang Luong of Calif.io","status":"published","published":"2026-04-08T15:09:05Z","modified":"2026-04-08T15:09:06Z","cvss":[{"version":"4.0","score":8.4,"vector":"CVSS:4.0/AV:L/AC:L/AT:N/PR:N/UI:A/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N","level":"high"},{"version":"3.1","score":5,"vector":"CVSS:3.1/AV:L/AC:L/PR:L/UI:R/S:U/C:N/I:N/A:H","level":"medium"}],"cwes":["CWE-190","CWE-787"],"updated_at":"2026-11-02T14:39:51.193071Z"}],"nvd":[{"id":"CVE-2026-34589","description":"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.","status":"published","published":"2026-04-06T16:16:36.04Z","modified":"2026-10-26T22:10:00.163Z","cvss":[{"version":"4.0","score":8.4,"vector":"CVSS:4.0/AV:L/AC:L/AT:N/PR:N/UI:A/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X","level":"high","assessor":"secondary"},{"version":"3.1","score":5,"vector":"CVSS:3.1/AV:L/AC:L/PR:L/UI:R/S:U/C:N/I:N/A:H","level":"medium","assessor":"primary"},{"version":"3.1","score":8.8,"vector":"CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H","level":"high","assessor":"secondary"}],"cwes":["CWE-190","CWE-787"],"updated_at":"2026-11-02T14:12:13.1424Z"}],"osv":[{"id":"ALPINE-CVE-2026-34589","description":"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.","status":"published","published":"2026-04-06T16:16:36.04Z","modified":"2026-11-03T06:32:55.182670544Z","cvss":[{"version":"3.1","score":5,"vector":"CVSS:3.1/AV:L/AC:L/PR:L/UI:R/S:U/C:N/I:N/A:H","level":"medium"}],"updated_at":"2026-11-03T07:16:26.770911Z"},{"id":"BELL-CVE-2026-34589","status":"published","published":"2026-04-07T06:09:09.239392Z","modified":"2026-04-09T07:20:32.537916Z","cvss":[{"version":"3.1","score":5,"vector":"CVSS:3.1/AV:L/AC:L/PR:L/UI:R/S:U/C:N/I:N/A:H","level":"medium"}],"updated_at":"2026-11-02T15:28:23.572955Z"},{"id":"CVE-2026-34589","title":"OpenEXR: DWA Lossy Decoder Heap Out-of-Bounds Write","description":"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.","status":"published","published":"2026-04-06T15:33:03.276Z","modified":"2026-10-28T02:30:25.296901915Z","cvss":[{"version":"4.0","score":8.4,"vector":"CVSS:4.0/AV:L/AC:L/AT:N/PR:N/UI:A/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N","level":"high"}],"cwes":["CWE-190","CWE-787"],"updated_at":"2026-11-02T15:45:02.247031Z"},{"id":"DEBIAN-CVE-2026-34589","description":"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.","status":"published","published":"2026-04-06T16:16:36.04Z","modified":"2026-10-27T10:01:04.576138895Z","cvss":[{"version":"3.1","score":5,"vector":"CVSS:3.1/AV:L/AC:L/PR:L/UI:R/S:U/C:N/I:N/A:H","level":"medium"}],"updated_at":"2026-11-02T15:45:54.587575Z"},{"id":"GHSA-p8xc-w3q4-h64x","title":"OpenEXR: DWA Lossy Decoder Heap Out-of-Bounds Write","description":"## Summary\n\nThe 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.\n\nThis bug is reachable from the public decoder path and can be reproduced through the shipped `exrcheck` tool with a crafted scanline DWAA file. The confirmed dynamic symptom is a write-side crash in the lossy DCT execution path.\n\nTested on commit: 7820b7e1b93405ba1d551c43a945018226b75bc5\n\n## Root Cause and Data Flow\n\nThe vulnerable pointer construction lives in `src/lib/OpenEXRCore/internal_dwa_decoder.h`:\n\n```c\nfor (int comp = 1; comp \u003c numComp; ++comp)\n    rowBlock[comp] = rowBlock[comp - 1] + numBlocksX * 64;\n```\n\nThe expression `numBlocksX * 64` is computed as signed `int`. Once `numBlocksX` is large enough, the multiplication wraps, and `rowBlock[comp]` points backward rather than forward into the temporary decode buffer.\n\nLater, `LossyDctDecoder_execute()` uses those derived pointers for real loads and stores during the block shuffle and reconstruction process. At that point the decoder is no longer operating within the bounds of the allocation created for `rowBlockHandle`.\n\nThe public control flow is the standard one:\n\n```c\nInputFile / ScanLineInputFile public read\n  -\u003e exr_decoding_run(...)\n     -\u003e exr_uncompress_chunk(...)\n        -\u003e internal_exr_undo_dwaa(...)\n           -\u003e DwaCompressor_uncompress(...)\n              -\u003e LossyDctDecoder_execute(...)\n```\n\nUBSan gives a clean root-cause diagnosis on the overflowing multiply, while ASAN shows the later memory error in the write-side decode path.\n\n## Reproduction\n\n[dwa_scanline_exrcheck.zip](https://github.com/user-attachments/files/26318786/dwa_scanline_exrcheck.zip)\n\nBuild with `exrcheck` with ASAN and run:\n\n```\n❯ ./build-asan/bin/exrcheck /tmp/dwa_scanline_exrcheck.exr\n file /tmp/dwa_scanline_exrcheck.exr /home/pop/sec/openexr/src/lib/OpenEXRCore/internal_dwa_decoder.h:331:58: runtime error: signed integer overflow: 33554432 * 64 cannot be represented in type 'int'\nAddressSanitizer:DEADLYSIGNAL\n=================================================================\n==1684058==ERROR: AddressSanitizer: SEGV on unknown address 0x758f8e5f0800 (pc 0x75979e850336 bp 0x7ffe8f1d3420 sp 0x7ffe8f1d30f0 T0)\n==1684058==The signal is caused by a WRITE memory access.\n    #0 0x75979e850336 in LossyDctDecoder_execute /home/pop/sec/openexr/src/lib/OpenEXRCore/internal_dwa_decoder.h:524\n    #1 0x75979e879592 in DwaCompressor_uncompress /home/pop/sec/openexr/src/lib/OpenEXRCore/internal_dwa_compressor.h:1210\n    #2 0x75979e879592 in internal_exr_undo_dwaa /home/pop/sec/openexr/src/lib/OpenEXRCore/internal_dwa.c:231\n    #3 0x75979e95f878 in exr_uncompress_chunk /home/pop/sec/openexr/src/lib/OpenEXRCore/compression.c:542\n    #4 0x75979e9659a8 in exr_decoding_run /home/pop/sec/openexr/src/lib/OpenEXRCore/decoding.c:580\n    #5 0x7597a0271add in run_decode /home/pop/sec/openexr/src/lib/OpenEXR/ImfScanLineInputFile.cpp:586\n    #6 0x7597a0283dc4 in Imf_4_0::ScanLineInputFile::Data::readPixels(Imf_4_0::FrameBuffer const\u0026, int, int) /home/pop/sec/openexr/src/lib/OpenEXR/ImfScanLineInputFile.cpp:500\n    #7 0x7597a00c6a81 in Imf_4_0::InputFile::Data::readPixels(int, int) /home/pop/sec/openexr/src/lib/OpenEXR/ImfInputFile.cpp:458\n    #8 0x7597a13fe2dc in readScanline\u003cImf_4_0::InputPart\u003e /home/pop/sec/openexr/src/lib/OpenEXRUtil/ImfCheckFile.cpp:239\n    #9 0x7597a1405b04 in readMultiPart /home/pop/sec/openexr/src/lib/OpenEXRUtil/ImfCheckFile.cpp:905\n    #10 0x7597a14126fd in runChecks\u003cchar const*\u003e /home/pop/sec/openexr/src/lib/OpenEXRUtil/ImfCheckFile.cpp:1171\n    #11 0x7597a14146b9 in Imf_4_0::checkOpenEXRFile(char const*, bool, bool, bool) /home/pop/sec/openexr/src/lib/OpenEXRUtil/ImfCheckFile.cpp:1835\n    #12 0x61ba9582b8f8 in exrCheck(char const*, bool, bool, bool, bool) /home/pop/sec/openexr/src/bin/exrcheck/main.cpp:96\n    #13 0x61ba958282b1 in main /home/pop/sec/openexr/src/bin/exrcheck/main.cpp:164\n    #14 0x75979d62a1c9 in __libc_start_call_main ../sysdeps/nptl/libc_start_call_main.h:58\n    #15 0x75979d62a28a in __libc_start_main_impl ../csu/libc-start.c:360\n    #16 0x61ba95829844 in _start (/home/pop/sec/openexr/build-asan/bin/exrcheck+0xe844) (BuildId: 087c972343a5372940c42c0a2e7bce4a84288aec)\n\nAddressSanitizer can not provide additional info.\nSUMMARY: AddressSanitizer: SEGV /home/pop/sec/openexr/src/lib/OpenEXRCore/internal_dwa_decoder.h:524 in LossyDctDecoder_execute\n==1684058==ABORTING\n```\n-------\nFound by: Quang Luong of Calif.io","status":"published","published":"2026-04-08T15:09:05Z","modified":"2026-07-13T16:43:24.943387949Z","cvss":[{"version":"3.1","score":5,"vector":"CVSS:3.1/AV:L/AC:L/PR:L/UI:R/S:U/C:N/I:N/A:H","level":"medium"},{"version":"4.0","score":8.4,"vector":"CVSS:4.0/AV:L/AC:L/AT:N/PR:N/UI:A/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N","level":"high"}],"cwes":["CWE-190","CWE-787"],"updated_at":"2026-11-02T15:46:52.891208Z"},{"id":"JLSEC-2026-149","description":"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.","status":"published","published":"2026-04-17T15:19:54.657Z","modified":"2026-07-18T00:00:24.277291227Z","cvss":[{"version":"3.1","score":5,"vector":"CVSS:3.1/AV:L/AC:L/PR:L/UI:R/S:U/C:N/I:N/A:H","level":"medium"},{"version":"4.0","score":8.4,"vector":"CVSS:4.0/AV:L/AC:L/AT:N/PR:N/UI:A/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X","level":"high"}],"updated_at":"2026-11-02T15:47:18.159338Z"},{"id":"OESA-2026-1840","title":"OpenEXR security update","description":"OpenEXR is a high dynamic-range (HDR) image file format originally developed by Industrial Light \u0026amp;amp; Magic for use in computer imaging applications.\r\n\r\nSecurity Fix(es):\n\nOpenEXR 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-34379)\n\nOpenEXR 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\u0026apos;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-34380)\n\nOpenEXR 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-34588)\n\nOpenEXR 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.(CVE-2026-34589)","status":"published","published":"2026-04-11T11:10:51Z","modified":"2026-08-18T01:19:45.862772708Z","cvss":[{"version":"3.1","score":7.8,"vector":"CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H","level":"high"}],"updated_at":"2026-11-02T15:52:46.087701Z"},{"id":"OESA-2026-1841","title":"OpenEXR security update","description":"OpenEXR is a high dynamic-range (HDR) image file format originally developed by Industrial Light \u0026amp;amp; Magic for use in computer imaging applications.\r\n\r\nSecurity Fix(es):\n\nOpenEXR 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-34379)\n\nOpenEXR 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\u0026apos;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-34380)\n\nOpenEXR 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-34588)\n\nOpenEXR 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.(CVE-2026-34589)","status":"published","published":"2026-04-11T11:10:51Z","modified":"2026-08-18T01:19:47.022098631Z","cvss":[{"version":"3.1","score":7.8,"vector":"CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H","level":"high"}],"updated_at":"2026-11-02T15:52:46.087701Z"},{"id":"OESA-2026-1842","title":"OpenEXR security update","description":"OpenEXR is a high dynamic-range (HDR) image file format originally developed by Industrial Light \u0026amp;amp; Magic for use in computer imaging applications.\r\n\r\nSecurity Fix(es):\n\nOpenEXR 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-34379)\n\nOpenEXR 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\u0026apos;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-34380)\n\nOpenEXR 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-34588)\n\nOpenEXR 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.(CVE-2026-34589)","status":"published","published":"2026-04-11T11:10:51Z","modified":"2026-08-18T01:19:45.920336254Z","cvss":[{"version":"3.1","score":7.8,"vector":"CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H","level":"high"}],"updated_at":"2026-11-02T15:52:46.087701Z"},{"id":"OESA-2026-1843","title":"OpenEXR security update","description":"OpenEXR is a high dynamic-range (HDR) image file format originally developed by Industrial Light \u0026amp;amp; Magic for use in computer imaging applications.\r\n\r\nSecurity Fix(es):\n\nOpenEXR 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-34379)\n\nOpenEXR 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\u0026apos;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-34380)\n\nOpenEXR 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-34588)\n\nOpenEXR 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.(CVE-2026-34589)","status":"published","published":"2026-04-11T11:10:51Z","modified":"2026-08-18T01:19:47.058802697Z","cvss":[{"version":"3.1","score":7.8,"vector":"CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H","level":"high"}],"updated_at":"2026-11-02T15:52:46.087701Z"},{"id":"OESA-2026-1844","title":"OpenEXR security update","description":"OpenEXR is a high dynamic-range (HDR) image file format originally developed by Industrial Light \u0026amp;amp; Magic for use in computer imaging applications.\r\n\r\nSecurity Fix(es):\n\nOpenEXR 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\u0026apos;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-34380)\n\nOpenEXR 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.(CVE-2026-34589)","status":"published","published":"2026-04-11T11:10:51Z","modified":"2026-08-18T01:19:46.187000841Z","cvss":[{"version":"3.1","score":5.9,"vector":"CVSS:3.1/AV:N/AC:H/PR:N/UI:R/S:U/C:N/I:L/A:H","level":"medium"}],"updated_at":"2026-11-02T15:52:46.087701Z"},{"id":"PYSEC-2026-2848","title":"OpenEXR: DWA Lossy Decoder Heap Out-of-Bounds Write","description":"## Summary\n\nThe 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.\n\nThis bug is reachable from the public decoder path and can be reproduced through the shipped `exrcheck` tool with a crafted scanline DWAA file. The confirmed dynamic symptom is a write-side crash in the lossy DCT execution path.\n\nTested on commit: 7820b7e1b93405ba1d551c43a945018226b75bc5\n\n## Root Cause and Data Flow\n\nThe vulnerable pointer construction lives in `src/lib/OpenEXRCore/internal_dwa_decoder.h`:\n\n```c\nfor (int comp = 1; comp \u003c numComp; ++comp)\n    rowBlock[comp] = rowBlock[comp - 1] + numBlocksX * 64;\n```\n\nThe expression `numBlocksX * 64` is computed as signed `int`. Once `numBlocksX` is large enough, the multiplication wraps, and `rowBlock[comp]` points backward rather than forward into the temporary decode buffer.\n\nLater, `LossyDctDecoder_execute()` uses those derived pointers for real loads and stores during the block shuffle and reconstruction process. At that point the decoder is no longer operating within the bounds of the allocation created for `rowBlockHandle`.\n\nThe public control flow is the standard one:\n\n```c\nInputFile / ScanLineInputFile public read\n  -\u003e exr_decoding_run(...)\n     -\u003e exr_uncompress_chunk(...)\n        -\u003e internal_exr_undo_dwaa(...)\n           -\u003e DwaCompressor_uncompress(...)\n              -\u003e LossyDctDecoder_execute(...)\n```\n\nUBSan gives a clean root-cause diagnosis on the overflowing multiply, while ASAN shows the later memory error in the write-side decode path.\n\n## Reproduction\n\n[dwa_scanline_exrcheck.zip](https://github.com/user-attachments/files/26318786/dwa_scanline_exrcheck.zip)\n\nBuild with `exrcheck` with ASAN and run:\n\n```\n❯ ./build-asan/bin/exrcheck /tmp/dwa_scanline_exrcheck.exr\n file /tmp/dwa_scanline_exrcheck.exr /home/pop/sec/openexr/src/lib/OpenEXRCore/internal_dwa_decoder.h:331:58: runtime error: signed integer overflow: 33554432 * 64 cannot be represented in type 'int'\nAddressSanitizer:DEADLYSIGNAL\n=================================================================\n==1684058==ERROR: AddressSanitizer: SEGV on unknown address 0x758f8e5f0800 (pc 0x75979e850336 bp 0x7ffe8f1d3420 sp 0x7ffe8f1d30f0 T0)\n==1684058==The signal is caused by a WRITE memory access.\n    #0 0x75979e850336 in LossyDctDecoder_execute /home/pop/sec/openexr/src/lib/OpenEXRCore/internal_dwa_decoder.h:524\n    #1 0x75979e879592 in DwaCompressor_uncompress /home/pop/sec/openexr/src/lib/OpenEXRCore/internal_dwa_compressor.h:1210\n    #2 0x75979e879592 in internal_exr_undo_dwaa /home/pop/sec/openexr/src/lib/OpenEXRCore/internal_dwa.c:231\n    #3 0x75979e95f878 in exr_uncompress_chunk /home/pop/sec/openexr/src/lib/OpenEXRCore/compression.c:542\n    #4 0x75979e9659a8 in exr_decoding_run /home/pop/sec/openexr/src/lib/OpenEXRCore/decoding.c:580\n    #5 0x7597a0271add in run_decode /home/pop/sec/openexr/src/lib/OpenEXR/ImfScanLineInputFile.cpp:586\n    #6 0x7597a0283dc4 in Imf_4_0::ScanLineInputFile::Data::readPixels(Imf_4_0::FrameBuffer const\u0026, int, int) /home/pop/sec/openexr/src/lib/OpenEXR/ImfScanLineInputFile.cpp:500\n    #7 0x7597a00c6a81 in Imf_4_0::InputFile::Data::readPixels(int, int) /home/pop/sec/openexr/src/lib/OpenEXR/ImfInputFile.cpp:458\n    #8 0x7597a13fe2dc in readScanline\u003cImf_4_0::InputPart\u003e /home/pop/sec/openexr/src/lib/OpenEXRUtil/ImfCheckFile.cpp:239\n    #9 0x7597a1405b04 in readMultiPart /home/pop/sec/openexr/src/lib/OpenEXRUtil/ImfCheckFile.cpp:905\n    #10 0x7597a14126fd in runChecks\u003cchar const*\u003e /home/pop/sec/openexr/src/lib/OpenEXRUtil/ImfCheckFile.cpp:1171\n    #11 0x7597a14146b9 in Imf_4_0::checkOpenEXRFile(char const*, bool, bool, bool) /home/pop/sec/openexr/src/lib/OpenEXRUtil/ImfCheckFile.cpp:1835\n    #12 0x61ba9582b8f8 in exrCheck(char const*, bool, bool, bool, bool) /home/pop/sec/openexr/src/bin/exrcheck/main.cpp:96\n    #13 0x61ba958282b1 in main /home/pop/sec/openexr/src/bin/exrcheck/main.cpp:164\n    #14 0x75979d62a1c9 in __libc_start_call_main ../sysdeps/nptl/libc_start_call_main.h:58\n    #15 0x75979d62a28a in __libc_start_main_impl ../csu/libc-start.c:360\n    #16 0x61ba95829844 in _start (/home/pop/sec/openexr/build-asan/bin/exrcheck+0xe844) (BuildId: 087c972343a5372940c42c0a2e7bce4a84288aec)\n\nAddressSanitizer can not provide additional info.\nSUMMARY: AddressSanitizer: SEGV /home/pop/sec/openexr/src/lib/OpenEXRCore/internal_dwa_decoder.h:524 in LossyDctDecoder_execute\n==1684058==ABORTING\n```\n-------\nFound by: Quang Luong of Calif.io","status":"published","published":"2026-07-13T14:36:49.83151Z","modified":"2026-07-13T16:32:33.950478683Z","cvss":[{"version":"3.1","score":5,"vector":"CVSS:3.1/AV:L/AC:L/PR:L/UI:R/S:U/C:N/I:N/A:H","level":"medium"},{"version":"4.0","score":8.4,"vector":"CVSS:4.0/AV:L/AC:L/AT:N/PR:N/UI:A/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N","level":"high"}],"updated_at":"2026-11-02T15:52:56.429374Z"},{"id":"ROOT-OS-DEBIAN-11-CVE-2026-34589","title":"CVE-2026-34589 in openexr - Patched by Root","description":"Root has patched CVE-2026-34589 in the openexr package for Root:Debian:11. Multiple fixed versions available.","status":"published","published":"2026-09-02T12:13:16Z","modified":"2026-09-02T14:00:15.469586347Z","cvss":[{"version":"3.1","score":5,"vector":"CVSS:3.1/AV:L/AC:L/PR:L/UI:R/S:U/C:N/I:N/A:H","level":"medium"}],"updated_at":"2026-11-02T15:53:29.900552Z"},{"id":"ROOT-OS-DEBIAN-12-CVE-2026-34589","title":"CVE-2026-34589 in openexr - Patched by Root","description":"Root has patched CVE-2026-34589 in the openexr package for Root:Debian:12. Multiple fixed versions available.","status":"published","published":"2026-09-02T11:23:23Z","modified":"2026-09-02T12:30:03.02325268Z","cvss":[{"version":"3.1","score":5,"vector":"CVSS:3.1/AV:L/AC:L/PR:L/UI:R/S:U/C:N/I:N/A:H","level":"medium"}],"updated_at":"2026-11-02T15:53:32.037361Z"},{"id":"ROOT-OS-DEBIAN-13-CVE-2026-34589","title":"CVE-2026-34589 in openexr - Patched by Root","description":"Root has patched CVE-2026-34589 in the openexr package for Root:Debian:13. Multiple fixed versions available.","status":"published","published":"2026-09-02T12:18:43Z","modified":"2026-09-02T14:00:10.240403437Z","cvss":[{"version":"3.1","score":5,"vector":"CVSS:3.1/AV:L/AC:L/PR:L/UI:R/S:U/C:N/I:N/A:H","level":"medium"}],"updated_at":"2026-11-02T15:53:33.415244Z"},{"id":"UBUNTU-CVE-2026-34589","description":"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.","status":"published","published":"2026-04-06T16:16:00Z","modified":"2026-10-17T12:58:12.019860797Z","cvss":[{"version":"4.0","score":8.4,"vector":"CVSS:4.0/AV:L/AC:L/AT:N/PR:N/UI:A/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N","level":"high"},{"version":"3.1","score":8.8,"vector":"CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H","level":"high"},{"version":"3.1","score":5,"vector":"CVSS:3.1/AV:L/AC:L/PR:L/UI:R/S:U/C:N/I:N/A:H","level":"medium"}],"updated_at":"2026-11-02T16:56:16.036833Z"},{"id":"openSUSE-SU-2026:10505-1","title":"libIex-3_4-33-3.4.9-1.1 on GA media","description":"These are all security issues fixed in the libIex-3_4-33-3.4.9-1.1 package on the GA media of openSUSE Tumbleweed.","status":"published","published":"2026-04-08T00:00:00Z","modified":"2026-04-09T08:00:37.097659Z","updated_at":"2026-11-02T16:58:38.415593Z"},{"id":"openSUSE-SU-2026:20605-1","title":"Security update for openexr","description":"This update for openexr fixes the following issues:\n\n- CVE-2026-34379: misaligned memory write during file decoding can cause a denial of service (bsc#1261621).\n- CVE-2026-34380: lack of proper check can lead to integer overflow in image decoding (bsc#1261622).\n- CVE-2026-34588: crafted EXR file can lead to out of bound read and write (bsc#1261624).\n- CVE-2026-34589: crafted scanline DWAA file can lead to arbitrary code execution or denial of service (bsc#1261634).\n","status":"published","published":"2026-04-22T10:03:51Z","modified":"2026-04-24T08:15:58.193379Z","updated_at":"2026-11-02T16:58:41.463445Z"},{"id":"SUSE-SU-2026:21372-1","title":"Security update for openexr","description":"This update for openexr fixes the following issues:\n\n- CVE-2026-34379: misaligned memory write during file decoding can cause a denial of service (bsc#1261621).\n- CVE-2026-34380: lack of proper check can lead to integer overflow in image decoding (bsc#1261622).\n- CVE-2026-34588: crafted EXR file can lead to out of bound read and write (bsc#1261624).\n- CVE-2026-34589: crafted scanline DWAA file can lead to arbitrary code execution or denial of service (bsc#1261634).\n","status":"published","published":"2026-04-22T10:07:59Z","modified":"2026-04-29T18:23:57.798743Z","updated_at":"2026-11-02T15:54:02.312556Z"}]}}