Логотип exploitDog
Консоль
Логотип exploitDog

exploitDog

debian логотип

CVE-2025-59732

Опубликовано: 06 окт. 2025
Источник: debian

Описание

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.

Пакеты

ПакетСтатусВерсия исправленияРелизТип
ffmpegfixed7:7.1.2-1package

Примечания

  • https://issuetracker.google.com/issues/436510316

  • Fixed by: https://git.ffmpeg.org/gitweb/ffmpeg.git/commit/f45da79b2c336c5f8f3e563d72b8a22fecdcde0c (n8.0)

  • Fixed by: https://git.ffmpeg.org/gitweb/ffmpeg.git/commit/97932677dbc29c1173f3361886022426ac74197e (n7.1.2)

  • Fixed by: https://git.ffmpeg.org/gitweb/ffmpeg.git/commit/fa543b33f63478090137d124c20ff97f76251254 (n6.1.3)

  • Fixed by: https://git.ffmpeg.org/gitweb/ffmpeg.git/commit/20708b957e8d4d57801c0b7ac52131988b093a49 (n5.1.7)

Связанные уязвимости

ubuntu
около 2 месяцев назад

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.

nvd
около 2 месяцев назад

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.

github
около 2 месяцев назад

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.

CVSS3: 6.4
fstec
4 месяца назад

Уязвимость функции uncompressed_data мультимедийной библиотеки FFmpeg, позволяющая нарушителю выполнить произвольный код

CVSS3: 7.5
redos
21 день назад

Множественные уязвимости ffmpeg