Nixpkgs security tracker

Login with GitHub

Suggestions search

With package: openexr_2

Found 4 matching suggestions

View:
Compact
Detailed
Untriaged
created 2 weeks, 1 day ago
OpenEXR: DWA Lossy Decoder Heap Out-of-Bounds Write

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.

Affected products

openexr
  • ==>= 3.4.0, < 3.4.9
  • ==>= 3.2.0, < 3.2.7
  • ==>= 3.3.0, < 3.3.9

Matching in nixpkgs

pkgs.openexr

High dynamic-range (HDR) image file format

Package maintainers

Untriaged
Permalink CVE-2026-34379
7.1 HIGH
  • CVSS version: 3.1
  • Attack vector (AV): NETWORK
  • Attack complexity (AC): LOW
  • Privileges required (PR): NONE
  • User interaction (UI): REQUIRED
  • Scope (S): UNCHANGED
  • Confidentiality impact (C): NONE
  • Integrity impact (I): LOW
  • Availability impact (A): HIGH
created 2 weeks, 1 day ago
OpenEXR has a misaligned write in LossyDctDecoder_execute leading to undefined behavior (DWA/DWAB decompression)

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.

Affected products

openexr
  • ==>= 3.4.0, < 3.4.9
  • ==>= 3.2.0, < 3.2.7
  • ==>= 3.3.0, < 3.3.9

Matching in nixpkgs

pkgs.openexr

High dynamic-range (HDR) image file format

Package maintainers

Untriaged
created 2 weeks, 1 day ago
OpenEXR has a signed 32-bit Overflow in PIZ Decoder Leads to OOB Read/Write

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.

Affected products

openexr
  • ==>= 3.4.0, < 3.4.9
  • ==>= 3.1.0, <= 3.1.13
  • ==>= 3.3.0, < 3.3.9
  • ==>= 3.2.0, < 3.2.7

Matching in nixpkgs

pkgs.openexr

High dynamic-range (HDR) image file format

Package maintainers

Published
updated 1 month, 2 weeks ago by @LeSuisse Activity log
  • Created automatic suggestion
  • @LeSuisse ignored
    2 packages
    • haskellPackages.openexr-write
    • openexrid-unstable
  • @LeSuisse accepted
  • @LeSuisse published on GitHub
OpenEXR CompositeDeepScanLine integer-overflow leads to heap OOB write

OpenEXR provides the specification and reference implementation of the EXR file format, an image storage format for the motion picture industry. In CompositeDeepScanLine::readPixels, per-pixel totals are accumulated in vector<unsigned int> total_sizes for attacker-controlled large counts across many parts, total_sizes[ptr] wraps modulo 2^32. overall_sample_count is then derived from wrapped totals and used in samples[channel].resize(overall_sample_count). Decode pointer setup/consumption proceeds with true sample counts, and write operations in core unpack (generic_unpack_deep_pointers) overrun the undersized composite sample buffer. This vulnerability is fixed in v3.2.6, v3.3.8, and v3.4.6.

Affected products

openexr
  • ==>= 2.3.0, < 3.2.6
  • ==>= 3.3.0, < 3.3.8
  • ==>= 3.4.0, < 3.4.6

Matching in nixpkgs

pkgs.openexr

High dynamic-range (HDR) image file format

Ignored packages (2)

Package maintainers

Upstream advisory: https://github.com/AcademySoftwareFoundation/openexr/security/advisories/GHSA-cr4v-6jm6-4963