apk package
chainguard/ffmpeg-7.1-libavformat61
pkg:apk/chainguard/ffmpeg-7.1-libavformat61
Vulnerabilities (6)
| CVE | Sev | CVSS | KEV | Affected versions | Fixed in | Published | Description |
|---|---|---|---|---|---|---|---|
| CVE-2025-59734 | Hig | — | < 7.1.2-r0 | 7.1.2-r0 | Oct 6, 2025 | It is possible to cause an use-after-free write in SANM decoding with a carefully crafted animation using subversion <2. When a STOR chunk is present, a subsequent FOBJ chunk will be saved in ctx->stored_frame. Stored frames can later be referenced by FTCH chunks. For files usin | |
| CVE-2025-59733 | Hig | — | < 7.1.2-r0 | 7.1.2-r0 | Oct 6, 2025 | When decoding an OpenEXR file that uses DWAA or DWAB compression, there's an implicit assumption that all image channels have the same pixel type (and size), and that if there are four channels, the first four are "B", "G", "R" and "A". The channel parsing code can be found in de | |
| CVE-2025-59732 | Hig | — | < 7.1.2-r0 | 7.1.2-r0 | Oct 6, 2025 | 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 | |
| CVE-2025-59731 | Med | — | < 7.1.2-r0 | 7.1.2-r0 | Oct 6, 2025 | When decoding an OpenEXR file that uses DWAA or DWAB compression, the specified raw length of run-length-encoded data is not checked when using it to calculate the output data. We read rle_raw_size from the input file at [0], we decompress and decode into the buffer td->rle_raw_ | |
| CVE-2025-59730 | Med | — | < 7.1.3-r1 | 7.1.3-r1 | Oct 6, 2025 | When decoding a frame for a SANM file (ANIM v0 variant), the decoded data can be larger than the buffer allocated for it. Frames encoded with codec 48 can specify their resolution (width x height). A buffer of appropriate size is allocated depending on the resolution. This code | |
| CVE-2025-59729 | Med | — | < 7.1.2-r0 | 7.1.2-r0 | Oct 6, 2025 | When parsing the header for a DHAV file, there's an integer underflow in offset calculation that leads to reading the duration from before the start of the allocated buffer. If we load a DHAV file that is larger than MAX_DURATION_BUFFER_SIZE bytes (0x100000) for example 0x101000 |
- affected < 7.1.2-r0fixed 7.1.2-r0
It is possible to cause an use-after-free write in SANM decoding with a carefully crafted animation using subversion <2. When a STOR chunk is present, a subsequent FOBJ chunk will be saved in ctx->stored_frame. Stored frames can later be referenced by FTCH chunks. For files usin
- affected < 7.1.2-r0fixed 7.1.2-r0
When decoding an OpenEXR file that uses DWAA or DWAB compression, there's an implicit assumption that all image channels have the same pixel type (and size), and that if there are four channels, the first four are "B", "G", "R" and "A". The channel parsing code can be found in de
- affected < 7.1.2-r0fixed 7.1.2-r0
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
- affected < 7.1.2-r0fixed 7.1.2-r0
When decoding an OpenEXR file that uses DWAA or DWAB compression, the specified raw length of run-length-encoded data is not checked when using it to calculate the output data. We read rle_raw_size from the input file at [0], we decompress and decode into the buffer td->rle_raw_
- affected < 7.1.3-r1fixed 7.1.3-r1
When decoding a frame for a SANM file (ANIM v0 variant), the decoded data can be larger than the buffer allocated for it. Frames encoded with codec 48 can specify their resolution (width x height). A buffer of appropriate size is allocated depending on the resolution. This code
- affected < 7.1.2-r0fixed 7.1.2-r0
When parsing the header for a DHAV file, there's an integer underflow in offset calculation that leads to reading the duration from before the start of the allocated buffer. If we load a DHAV file that is larger than MAX_DURATION_BUFFER_SIZE bytes (0x100000) for example 0x101000