Most recent entries from all

bdu:2026-12079

BELL-CVE-2026-34589

Affected: Alpaquita:stream: openexr

EUVD-2026-337311

fkie_cve-2026-34589

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.

GHSA-p8xc-w3q4-h64x — OpenEXR: DWA Lossy Decoder Heap Out-of-Bounds Write

Affected: PyPI: OpenEXR

## Summary

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 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.

Tested on commit: 7820b7e1b93405ba1d551c43a945018226b75bc5

## Root Cause and Data Flow

The vulnerable pointer construction lives in `src/lib/OpenEXRCore/internal_dwa_decoder.h`:

```c for (int comp = 1; comp < numComp; ++comp) rowBlock[comp] = rowBlock[comp - 1] + numBlocksX * 64; ```

The 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.

Later, `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`.

The public control flow is the standard one:

```c InputFile / ScanLineInputFile public read -> exr_decoding_run(...) -> exr_uncompress_chunk(...) -> internal_exr_undo_dwaa(...) -> DwaCompressor_uncompress(…

OESA-2026-1840 — OpenEXR security update

Affected: openEuler:24.03-LTS: OpenEXR

OpenEXR is a high dynamic-range (HDR) image file format originally developed by Industrial Light &amp; Magic for use in computer imaging applications. Security Fix(es):

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-34379)

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.…

openSUSE-SU-2026:10505-1 — libIex-3_4-33-3.4.9-1.1 on GA media

libIex-3_4-33-3.4.9-1.1 on GA media

PYSEC-2026-2848 — OpenEXR: DWA Lossy Decoder Heap Out-of-Bounds Write

Affected: PyPI: openexr

## Summary

Tested on commit: 7820b7e1b93405ba1d551c43a945018226b75bc5

## Root Cause and Data Flow

The vulnerable pointer construction lives in `src/lib/OpenEXRCore/internal_dwa_decoder.h`:

```c for (int comp = 1; comp < numComp; ++comp) rowBlock[comp] = rowBlock[comp - 1] + numBlocksX * 64; ```

The public control flow is the standard one:

```c InputFile / ScanLineInputFile public read -> exr_decoding_run(...) -> exr_uncompress_chunk(...) -> internal_exr_undo_dwaa(...) -> DwaCompressor_uncompress(…

SUSE-SU-2026:21372-1 — Security update for openexr

Security update for openexr

Withdrawn: UBUNTU-CVE-2026-34589

Withdrawn by the publisher.

Affected: Ubuntu:Pro:16.04:LTS: openexr, Ubuntu:18.04:LTS: openexr, Ubuntu:Pro:20.04:LTS: openexr, Ubuntu:Pro:22.04:LTS: openexr, Ubuntu:24.04:LTS: openexr, Ubuntu:25.10: openexr, Ubuntu:26.04: openexr

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.