Incorrect Type Conversion or Cast Affecting openexr package, versions <3.2.2-160000.6.1


Severity

Recommended
0.0
medium
0
10

Based on SUSE Linux Enterprise Server security rating.

Threat Intelligence

EPSS
0.28% (21st percentile)

Do your applications use this vulnerable package?

In a few clicks we can analyze your entire application and see what components are vulnerable in your application, and suggest you quick fixes.

Test your applications
  • Snyk IDSNYK-SLES1600-OPENEXR-16331454
  • published1 May 2026
  • disclosed22 Apr 2026

Introduced: 22 Apr 2026

CVE-2026-34379  (opens in a new tab)
CWE-704  (opens in a new tab)
CWE-787  (opens in a new tab)
CWE-843  (opens in a new tab)

How to fix?

Upgrade SLES:16.0.0 openexr to version 3.2.2-160000.6.1 or higher.

NVD Description

Note: Versions mentioned in the description apply only to the upstream openexr package and not the openexr package as distributed by SLES. See How to fix? for SLES:16.0.0 relevant fixed versions and status.

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.

CVSS Base Scores

version 3.1