Every CVE Search/ Get API key

CVE-2025-59729

Heap-buffer-overflow read in FFmpeg DHAV get_duration

5.7 MediumFix available

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 bytes, then at [0] we have size = 0x101000. At [1] we have end_buffer_size = 0x100000, and at [2] we have end_buffer_pos = 0x1000.

The loop then scans backwards through the buffer looking for the dhav tag; when it is found, we'll calculate end_pos based on a 32-bit offset read from the buffer.

There is subsequently a check [3] that end_pos is within the section of the file that has been copied into end_buffer, but it only correctly handles the cases where end_pos is before the start of the file or after the section copied into end_buffer, and not the case where end_pos is within the the file, but before the section copied into end_buffer. If we provide such an offset, (end_pos - end_buffer_pos) can underflow, resulting in the subsequent access at [4] occurring before the beginning of the allocation.

We recommend upgrading to version 8.0 or beyond.

Attack profile

How easy it is to exploit

Attack vector
Adjacent network
Complexity
High
Privileges needed
Low
User interaction
Passive

What an attacker can affect

Confidentiality
Low
Integrity
High
Availability
None

Exploit likelihood

0.16%Up 0.1 points since Oct 6, 2025
90%50%10%1%

What each source reports

CVE List Score used 5.7

Heap-buffer-overflow read in FFmpeg DHAV get_duration

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 bytes, then at [0] we have size = 0x101000. At [1] we have end_buffer_size = 0x100000, and at [2] we have end_buffer_pos = 0x1000.

The loop then scans backwards through the buffer looking for the dhav tag; when it is found, we'll calculate end_pos based on a 32-bit offset read from the buffer.

There is subsequently a check [3] that end_pos is within the section of the file that has been copied into end_buffer, but it only correctly handles the cases where end_pos is before the start of the file or after the section copied into end_buffer, and not the case where end_pos is within the the file, but before the section copied into end_buffer. If we provide such an offset, (end_pos - end_buffer_pos) can underflow, resulting in the subsequent access at [4] occurring before the beginning of the allocation.

We recommend upgrading to version 8.0 or beyond.

Record
CVE-2025-59729
CVSS 4.0
5.7 MediumCVSS:4.0/AV:A/AC:H/AT:P/PR:L/UI:P/VC:L/VI:H/VA:N/SC:L/SI:H/SA:N
Weakness
CWE-787
Updated
2026-11-02
EUVDEUVD-2025-32182 5.7

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 bytes, then at [0] we have size = 0x101000. At [1] we have end_buffer_size = 0x100000, and at [2] we have end_buffer_pos = 0x1000.

The loop then scans backwards through the buffer looking for the dhav tag; when it is found, we'll calculate end_pos based on a 32-bit offset read from the buffer.

There is subsequently a check [3] that end_pos is within the section of the file that has been copied into end_buffer, but it only correctly handles the cases where end_pos is before the start of the file or after the section copied into end_buffer, and not the case where end_pos is within the the file, but before the section copied into end_buffer. If we provide such an offset, (end_pos - end_buffer_pos) can underflow, resulting in the subsequent access at [4] occurring before the beginning of the allocation.

We recommend upgrading to version 8.0 or beyond.

Record
EUVD-2025-32182
CVSS 4.0
5.7 MediumCVSS:4.0/AV:A/AC:H/AT:P/PR:L/UI:P/VC:L/VI:H/VA:N/SC:L/SI:H/SA:N
Updated
2026-11-02
GitHub AdvisoriesGHSA-j8h4-v947-5h7q 5.7

When parsing the header for a DHAV file, there's an integer underflow in offset calculation that...

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 bytes, then at [0] we have size = 0x101000. At [1] we have end_buffer_size = 0x100000, and at [2] we have end_buffer_pos = 0x1000.

The loop then scans backwards through the buffer looking for the dhav tag; when it is found, we'll calculate end_pos based on a 32-bit offset read from the buffer.

There is subsequently a check [3] that end_pos is within the section of the file that has been copied into end_buffer, but it only correctly handles the cases where end_pos is before the start of the file or after the section copied into end_buffer, and not the case where end_pos is within the the file, but before the section copied into end_buffer. If we provide such an offset, (end_pos - end_buffer_pos) can underflow, resulting in the subsequent access at [4] occurring before the beginning of the allocation.

We recommend upgrading to version 8.0 or beyond.

Record
GHSA-j8h4-v947-5h7q
CVSS 4.0
5.7 MediumCVSS:4.0/AV:A/AC:H/AT:P/PR:L/UI:P/VC:L/VI:H/VA:N/SC:L/SI:H/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X
Weakness
CWE-787
Updated
2026-11-02
NVD 5.7

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 bytes, then at [0] we have size = 0x101000. At [1] we have end_buffer_size = 0x100000, and at [2] we have end_buffer_pos = 0x1000.

The loop then scans backwards through the buffer looking for the dhav tag; when it is found, we'll calculate end_pos based on a 32-bit offset read from the buffer.

There is subsequently a check [3] that end_pos is within the section of the file that has been copied into end_buffer, but it only correctly handles the cases where end_pos is before the start of the file or after the section copied into end_buffer, and not the case where end_pos is within the the file, but before the section copied into end_buffer. If we provide such an offset, (end_pos - end_buffer_pos) can underflow, resulting in the subsequent access at [4] occurring before the beginning of the allocation.

We recommend upgrading to version 8.0 or beyond.

Record
CVE-2025-59729
CVSS 4.0
5.7 MediumCVSS:4.0/AV:A/AC:H/AT:P/PR:L/UI:P/VC:L/VI:H/VA:N/SC:L/SI:H/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X
Weakness
CWE-787
Updated
2026-11-02
OSVALPINE-CVE-2025-59729 5.7

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 bytes, then at [0] we have size = 0x101000. At [1] we have end_buffer_size = 0x100000, and at [2] we have end_buffer_pos = 0x1000.

The loop then scans backwards through the buffer looking for the dhav tag; when it is found, we'll calculate end_pos based on a 32-bit offset read from the buffer.

There is subsequently a check [3] that end_pos is within the section of the file that has been copied into end_buffer, but it only correctly handles the cases where end_pos is before the start of the file or after the section copied into end_buffer, and not the case where end_pos is within the the file, but before the section copied into end_buffer. If we provide such an offset, (end_pos - end_buffer_pos) can underflow, resulting in the subsequent access at [4] occurring before the beginning of the allocation.

We recommend upgrading to version 8.0 or beyond.

Record
ALPINE-CVE-2025-59729
CVSS 4.0
5.7 MediumCVSS:4.0/AV:A/AC:H/AT:P/PR:L/UI:P/VC:L/VI:H/VA:N/SC:L/SI:H/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X
Updated
2026-11-03
OSV 5.7

Heap-buffer-overflow read in FFmpeg DHAV get_duration

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 bytes, then at [0] we have size = 0x101000. At [1] we have end_buffer_size = 0x100000, and at [2] we have end_buffer_pos = 0x1000.

The loop then scans backwards through the buffer looking for the dhav tag; when it is found, we'll calculate end_pos based on a 32-bit offset read from the buffer.

There is subsequently a check [3] that end_pos is within the section of the file that has been copied into end_buffer, but it only correctly handles the cases where end_pos is before the start of the file or after the section copied into end_buffer, and not the case where end_pos is within the the file, but before the section copied into end_buffer. If we provide such an offset, (end_pos - end_buffer_pos) can underflow, resulting in the subsequent access at [4] occurring before the beginning of the allocation.

We recommend upgrading to version 8.0 or beyond.

Record
CVE-2025-59729
CVSS 4.0
5.7 MediumCVSS:4.0/AV:A/AC:H/AT:P/PR:L/UI:P/VC:L/VI:H/VA:N/SC:L/SI:H/SA:N
Weakness
CWE-787
Updated
2026-11-02
OSVUBUNTU-CVE-2025-59729 5.7

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 bytes, then at [0] we have size = 0x101000. At [1] we have end_buffer_size = 0x100000, and at [2] we have end_buffer_pos = 0x1000. The loop then scans backwards through the buffer looking for the dhav tag; when it is found, we'll calculate end_pos based on a 32-bit offset read from the buffer. There is subsequently a check [3] that end_pos is within the section of the file that has been copied into end_buffer, but it only correctly handles the cases where end_pos is before the start of the file or after the section copied into end_buffer, and not the case where end_pos is within the the file, but before the section copied into end_buffer. If we provide such an offset, (end_pos - end_buffer_pos) can underflow, resulting in the subsequent access at [4] occurring before the beginning of the allocation. We recommend upgrading to version 8.0 or beyond.

Record
UBUNTU-CVE-2025-59729
CVSS 4.0
5.7 MediumCVSS:4.0/AV:A/AC:H/AT:P/PR:L/UI:P/VC:L/VI:H/VA:N/SC:L/SI:H/SA:N
Updated
2026-11-02
OSVDEBIAN-CVE-2025-59729 No score

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 bytes, then at [0] we have size = 0x101000. At [1] we have end_buffer_size = 0x100000, and at [2] we have end_buffer_pos = 0x1000. The loop then scans backwards through the buffer looking for the dhav tag; when it is found, we'll calculate end_pos based on a 32-bit offset read from the buffer. There is subsequently a check [3] that end_pos is within the section of the file that has been copied into end_buffer, but it only correctly handles the cases where end_pos is before the start of the file or after the section copied into end_buffer, and not the case where end_pos is within the the file, but before the section copied into end_buffer. If we provide such an offset, (end_pos - end_buffer_pos) can underflow, resulting in the subsequent access at [4] occurring before the beginning of the allocation. We recommend upgrading to version 8.0 or beyond.

Record
DEBIAN-CVE-2025-59729
Updated
2026-11-02

Affected products

Affected packages

Affected packages
PackageAffectedFixed
ffmpeg
Alpine:v3.23
before 8.0-r0
8.0-r0
ffmpeg
Alpine:v3.24
before 8.0-r0
8.0-r0
libav
Ubuntu:Pro:14.04:LTS
All versions, plus listed versions
6:0.8.7-1ubuntu26:9.10-1ubuntu16:9.10-1ubuntu26:9.10-1ubuntu56:9.10-1ubuntu6
Show 9 moreShow less
6:9.10-1ubuntu76:9.11-2ubuntu16:9.11-2ubuntu26:9.13-0ubuntu0.14.04.16:9.14-0ubuntu0.14.04.16:9.16-0ubuntu0.14.04.16:9.18-0ubuntu0.14.04.16:9.20-0ubuntu0.14.04.16:9.20-0ubuntu0.14.04.1+esm1
None known

History

History
RecordedChangedSources
affected, aliases, facts, referencesOSV
affected
first indexedCVE List, EUVD, GitHub Advisories, NVD, OSV

Dates are when Every CVE recorded each change. Upstream dates may differ.

In short

CVE-2025-59729 is a medium vulnerability (CVSS 5.7) in Ffmpeg, published October 6, 2025. No source lists public exploit code. EPSS puts the chance of exploitation in the next 30 days at 0.16%, the 5th percentile. Fixed in ffmpeg 8.0-r0.

References

MoveEnter Open