When decoding an OpenEXR file that uses DWAA or DWAB compression, there's an implicit assumption that the height and width are divisible by 8.

If the height or width of the image is not divisible by 8, the copy loops at [0] and [1] will continue to write until the next multiple of 8.

The buffer td->uncompressed_data is allocated in decode_block based on the precise height and width of the image, so the "rounded-up" multiple of 8 in the copy loop can exceed the buffer bounds, and the write block starting at [2] can corrupt following heap memory.



We recommend upgrading to version 8.0 or beyond.
Advisories
Source ID Title
EUVD EUVD EUVD-2025-32515 When decoding an OpenEXR file that uses DWAA or DWAB compression, there's an implicit assumption that the height and width are divisible by 8. If the height or width of the image is not divisible by 8, the copy loops at [0] and [1] will continue to write until the next multiple of 8. The buffer td->uncompressed_data is allocated in decode_block based on the precise height and width of the image, so the "rounded-up" multiple of 8 in the copy loop can exceed the buffer bounds, and the write block starting at [2] can corrupt following heap memory. We recommend upgrading to version 8.0 or beyond.
Fixes

Solution

No solution given by the vendor.


Workaround

No workaround given by the vendor.

References
History

Mon, 06 Oct 2025 17:15:00 +0000

Type Values Removed Values Added
Metrics ssvc

{'options': {'Automatable': 'no', 'Exploitation': 'none', 'Technical Impact': 'total'}, 'version': '2.0.3'}


Mon, 06 Oct 2025 14:45:00 +0000

Type Values Removed Values Added
First Time appeared Ffmpeg
Ffmpeg ffmpeg
Vendors & Products Ffmpeg
Ffmpeg ffmpeg

Mon, 06 Oct 2025 08:15:00 +0000

Type Values Removed Values Added
Description When decoding an OpenEXR file that uses DWAA or DWAB compression, there's an implicit assumption that the height and width are divisible by 8. If the height or width of the image is not divisible by 8, the copy loops at [0] and [1] will continue to write until the next multiple of 8. The buffer td->uncompressed_data is allocated in decode_block based on the precise height and width of the image, so the "rounded-up" multiple of 8 in the copy loop can exceed the buffer bounds, and the write block starting at [2] can corrupt following heap memory. We recommend upgrading to version 8.0 or beyond.
Title Heap-buffer-overflow write in FFmpeg EXR dwa_uncompress
Weaknesses CWE-787
References
Metrics cvssV4_0

{'score': 8.7, 'vector': 'CVSS:4.0/AV:A/AC:H/AT:N/PR:N/UI:P/VC:H/VI:H/VA:N/SC:H/SI:H/SA:N'}


cve-icon MITRE

Status: PUBLISHED

Assigner: Google

Published:

Updated: 2025-10-06T16:18:27.171Z

Reserved: 2025-09-19T08:11:37.550Z

Link: CVE-2025-59732

cve-icon Vulnrichment

Updated: 2025-10-06T16:18:18.178Z

cve-icon NVD

Status : Awaiting Analysis

Published: 2025-10-06T08:15:34.920

Modified: 2025-10-06T14:56:21.733

Link: CVE-2025-59732

cve-icon Redhat

No data.

cve-icon OpenCVE Enrichment

Updated: 2025-10-06T14:39:49Z