Conversation
3 tasks
danoli3
force-pushed
the
fix/openexr-idmanifest-dos
branch
from
September 14, 2026 14:15
f31a769 to
2c9d776
Compare
danoli3
changed the title
The full upstream 3.3.13->3.3.14 diff is exactly two source-relevant files: ImfIDManifest.cpp and the version header - everything else in that release is CI manifests/CHANGES.md. So this is a real version bump, not a partial cherry-pick. GHSA-rmgv-rm47-38g3: manifestEntries is read straight from the decompressed payload and passed to resize() with no bounds check - a 349-byte EXR declaring 20M entries forces ~2.9GB of resident memory, INT_MAX entries demands 288GiB. Reject negative counts and grow the vector with push_back instead of a single unchecked resize(). GHSA-5j5m-22wr-mhc6: the compressed manifest's declared _uncompressedDataSize is used as an allocation size before decompression, before anything in the payload has been validated - a 343-byte file can claim an arbitrary uncompressed size. Cap it by zlib's own ~1032:1 max expansion ratio relative to the actual compressed size present in the file, rather than an arbitrary constant (OpenEXR has no fixed image-size limit, so a large legitimate manifest must still be allowed). Source/OpenEXR/IlmImf/ImfIDManifest.cpp matched the pristine 3.3.13 release exactly, so this is the unmodified upstream fix. Note: the separate ARM64EC SIMD guard fix (companion PR) is NOT part of this bump - that fix was never backported to the 3.3.x release branch upstream, only to main/3.4.x, so it stays a standalone patch even after this version bump.
danoli3
force-pushed
the
fix/openexr-idmanifest-dos
branch
from
September 15, 2026 04:43
2c9d776 to
15ed366
Compare
danoli3
changed the title
This was referenced Sep 15, 2026
Owner
Author
|
Combined into #119. |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Bumps vendored OpenEXR 3.3.13 -> 3.3.14. Checked the full upstream diff between those tags first: it's exactly two source-relevant files (
ImfIDManifest.cpp+ the version header), everything else in that release is CI manifests/CHANGES.md - so this is a genuine version bump, not a partial cherry-pick dressed up as one.Fixes two unpatched holes in
Source/OpenEXR/IlmImf/ImfIDManifest.cpp:manifestEntriesis read straight from the decompressed payload and passed toresize()with no bounds check. A 349-byte EXR declaring 20M entries forces ~2.9GB resident,INT_MAXentries demands 288GiB._uncompressedDataSizeis used as an allocation size before decompression, before anything in the payload is validated - a 343-byte file can claim an arbitrary size.Fix
Cherry-picked verbatim from upstream 3.3.14 (
Source/OpenEXR/IlmImf/ImfIDManifest.cppmatched the pristine 3.3.13 release exactly, so no local FreeImage divergence to reconcile):manifestEntries; grow withpush_backinstead of one uncheckedresize().No CVE number assigned yet, GHSA-only.
Note: the separate ARM64EC SIMD guard fix (#113) is not part of this bump - that fix was never backported to the 3.3.x release branch upstream, only to main/3.4.x, so it stays a standalone patch even on top of 3.3.14.
The jump to latest (3.4.15) is real re-vendor work - new HTJ2K compressor, API changes across several headers - tracked separately, not bundled into this.