Skip to content

GHSA-9c7r-mp54-x46f on CTRL-OS 26.05

Aliases: GHSA-9c7r-mp54-x46f

Packages: openexr

Status: Plausible

Advisory Information

Summary: PR #2162 (commit 72aa3e7) added a guard to reject uncompressed EXR chunks where packed_size != unpacked_size, but applied it only to exr_read_tile_chunk_info. The scanline equivalent exr_read_scanline_chunk_info has no such guard.

Vulnerable code: src/lib/OpenEXRCore/chunk.c

The tile reader (line ~1491) has: if (compression == EXR_COMPRESSION_NONE && packed_size != unpacked_size) { return error; }

The scanline reader has no equivalent check.

Impact: A crafted uncompressed deep-scanline EXR with packed_size unpacked_size causes the decoder to allocate a separate unpacked_buffer (via malloc, not calloc) that is never filled by any decompression step — because for NONE compression the code expects packed == unpacked. The stale/uninitialized heap data in unpacked_buffer is then copied into the caller's pixel buffer, leaking heap contents to the application.

Allocator confirmed as malloc (memory.c:39), not zeroing.

Root cause: Incomplete fix — PR #2162 patched only the tile code path and missed the scanline path.

Affected versions: all versions containing PR #2162 Patched versions: none yet

Fix suggestion: Add to exr_read_scanline_chunk_info in chunk.c: if (cinfo->compression == EXR_COMPRESSION_NONE && cinfo->packed_size != cinfo->unpacked_size) return ctxt->print_error(ctxt, EXR_ERR_INVALID_ARGUMENT, "Uncompressed chunk: packed_size (%" PRId64 ") != " "unpacked_size (%" PRId64 ")", cinfo->packed_size, cinfo->unpacked_size);

Reported by: Yazan Balawneh - CyStack Security Team

Updates

2026-08-11 03:51 CEST

Metadata changes:

  • Status for package openexr: “Plausible”

2026-08-11 03:31 CEST

Metadata changes:

  • Status for package openexr: “New”