{"dataType": "CVE_RECORD", "dataVersion": "5.1", "cveMetadata": {"cveId": "CVE-2025-59729", "assignerOrgId": "14ed7db2-1595-443d-9d34-6215bf890778", "state": "PUBLISHED", "assignerShortName": "Google", "dateReserved": "2025-09-19T08:11:37.549Z", "datePublished": "2025-10-06T08:08:46.060Z", "dateUpdated": "2025-10-06T08:08:46.060Z"}, "containers": {"cna": {"affected": [{"collectionURL": "https://git.ffmpeg.org/ffmpeg.git", "defaultStatus": "unaffected", "modules": ["get_duration"], "packageName": "DHAV", "product": "FFmpeg", "repo": "https://git.ffmpeg.org/ffmpeg.git", "vendor": "FFmpeg", "versions": [{"lessThan": "8.0", "status": "affected", "version": "a218cafe4d3be005ab0c61130f90db4d21afb5db", "versionType": "custom"}]}], "credits": [{"lang": "en", "type": "finder", "value": "Google Big Sleep"}], "datePublic": "2025-07-21T22:00:00.000Z", "descriptions": [{"lang": "en", "supportingMedia": [{"base64": false, "type": "text/html", "value": "<p></p><p>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.</p><p>If we load a DHAV file that is larger than <code>MAX_DURATION_BUFFER_SIZE</code>&nbsp;bytes (<code>0x100000</code>) for example 0x101000 bytes, then at [0] we have <code>size = 0x101000</code>. At [1] we have <code>end_buffer_size = 0x100000</code>, and at [2] we have <code>end_buffer_pos = 0x1000</code>.</p><p>The loop then scans backwards through the buffer looking for the <code>dhav</code>&nbsp;tag; when it is found, we'll calculate <code>end_pos</code>&nbsp;based on a 32-bit offset read from the buffer.</p><p>There is subsequently a check [3] that <code>end_pos</code>&nbsp;is within the section of the file that has been copied into <code>end_buffer</code>, but it only correctly handles the cases where <code>end_pos</code>&nbsp;is <em>before the start of the file</em>&nbsp;or <em>after the section copied into <code>end_buffer</code></em>, and not the case where <code>end_pos</code>&nbsp;is within the the file, but before the section copied into <code>end_buffer</code>. If we provide such an offset, <code>(end_pos - end_buffer_pos)</code>&nbsp;can underflow, resulting in the subsequent access at [4] occurring before the beginning of the allocation.</p>We recommend upgrading to version 8.0 or beyond.<p></p><br>"}], "value": "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.\n\nIf we load a DHAV file that is larger than MAX_DURATION_BUFFER_SIZE\u00a0bytes (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.\n\nThe loop then scans backwards through the buffer looking for the dhav\u00a0tag; when it is found, we'll calculate end_pos\u00a0based on a 32-bit offset read from the buffer.\n\nThere is subsequently a check [3] that end_pos\u00a0is within the section of the file that has been copied into end_buffer, but it only correctly handles the cases where end_pos\u00a0is before the start of the file\u00a0or after the section copied into end_buffer, and not the case where end_pos\u00a0is within the the file, but before the section copied into end_buffer. If we provide such an offset, (end_pos - end_buffer_pos)\u00a0can underflow, resulting in the subsequent access at [4] occurring before the beginning of the allocation.\n\nWe recommend upgrading to version 8.0 or beyond."}], "impacts": [{"capecId": "CAPEC-100", "descriptions": [{"lang": "en", "value": "CAPEC-100 Overflow Buffers"}]}], "metrics": [{"cvssV4_0": {"Automatable": "NOT_DEFINED", "Recovery": "NOT_DEFINED", "Safety": "NOT_DEFINED", "attackComplexity": "HIGH", "attackRequirements": "PRESENT", "attackVector": "ADJACENT", "baseScore": 5.7, "baseSeverity": "MEDIUM", "privilegesRequired": "LOW", "providerUrgency": "NOT_DEFINED", "subAvailabilityImpact": "NONE", "subConfidentialityImpact": "LOW", "subIntegrityImpact": "HIGH", "userInteraction": "PASSIVE", "valueDensity": "NOT_DEFINED", "vectorString": "CVSS:4.0/AV:A/AC:H/AT:P/PR:L/UI:P/VC:L/VI:H/VA:N/SC:L/SI:H/SA:N", "version": "4.0", "vulnAvailabilityImpact": "NONE", "vulnConfidentialityImpact": "LOW", "vulnIntegrityImpact": "HIGH", "vulnerabilityResponseEffort": "NOT_DEFINED"}, "format": "CVSS", "scenarios": [{"lang": "en", "value": "GENERAL"}]}], "problemTypes": [{"descriptions": [{"cweId": "CWE-787", "description": "CWE-787 Out-of-bounds Write", "lang": "en", "type": "CWE"}]}], "providerMetadata": {"orgId": "14ed7db2-1595-443d-9d34-6215bf890778", "shortName": "Google", "dateUpdated": "2025-10-06T08:08:46.060Z"}, "references": [{"url": "https://issuetracker.google.com/433513232"}], "source": {"discovery": "EXTERNAL"}, "title": "Heap-buffer-overflow read in FFmpeg DHAV get_duration", "x_generator": {"engine": "Vulnogram 0.2.0"}}}}

{}

{"cveTags": [], "descriptions": [{"lang": "en", "value": "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.\n\nIf we load a DHAV file that is larger than MAX_DURATION_BUFFER_SIZE\u00a0bytes (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.\n\nThe loop then scans backwards through the buffer looking for the dhav\u00a0tag; when it is found, we'll calculate end_pos\u00a0based on a 32-bit offset read from the buffer.\n\nThere is subsequently a check [3] that end_pos\u00a0is within the section of the file that has been copied into end_buffer, but it only correctly handles the cases where end_pos\u00a0is before the start of the file\u00a0or after the section copied into end_buffer, and not the case where end_pos\u00a0is within the the file, but before the section copied into end_buffer. If we provide such an offset, (end_pos - end_buffer_pos)\u00a0can underflow, resulting in the subsequent access at [4] occurring before the beginning of the allocation.\n\nWe recommend upgrading to version 8.0 or beyond."}], "id": "CVE-2025-59729", "lastModified": "2025-10-06T08:15:34.447", "metrics": {"cvssMetricV40": [{"cvssData": {"Automatable": "NOT_DEFINED", "Recovery": "NOT_DEFINED", "Safety": "NOT_DEFINED", "attackComplexity": "HIGH", "attackRequirements": "PRESENT", "attackVector": "ADJACENT", "availabilityRequirement": "NOT_DEFINED", "baseScore": 5.7, "baseSeverity": "MEDIUM", "confidentialityRequirement": "NOT_DEFINED", "exploitMaturity": "NOT_DEFINED", "integrityRequirement": "NOT_DEFINED", "modifiedAttackComplexity": "NOT_DEFINED", "modifiedAttackRequirements": "NOT_DEFINED", "modifiedAttackVector": "NOT_DEFINED", "modifiedPrivilegesRequired": "NOT_DEFINED", "modifiedSubAvailabilityImpact": "NOT_DEFINED", "modifiedSubConfidentialityImpact": "NOT_DEFINED", "modifiedSubIntegrityImpact": "NOT_DEFINED", "modifiedUserInteraction": "NOT_DEFINED", "modifiedVulnAvailabilityImpact": "NOT_DEFINED", "modifiedVulnConfidentialityImpact": "NOT_DEFINED", "modifiedVulnIntegrityImpact": "NOT_DEFINED", "privilegesRequired": "LOW", "providerUrgency": "NOT_DEFINED", "subAvailabilityImpact": "NONE", "subConfidentialityImpact": "LOW", "subIntegrityImpact": "HIGH", "userInteraction": "PASSIVE", "valueDensity": "NOT_DEFINED", "vectorString": "CVSS: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", "version": "4.0", "vulnAvailabilityImpact": "NONE", "vulnConfidentialityImpact": "LOW", "vulnIntegrityImpact": "HIGH", "vulnerabilityResponseEffort": "NOT_DEFINED"}, "source": "cve-coordination@google.com", "type": "Secondary"}]}, "published": "2025-10-06T08:15:34.447", "references": [{"source": "cve-coordination@google.com", "url": "https://issuetracker.google.com/433513232"}], "sourceIdentifier": "cve-coordination@google.com", "vulnStatus": "Received", "weaknesses": [{"description": [{"lang": "en", "value": "CWE-787"}], "source": "cve-coordination@google.com", "type": "Secondary"}]}

{}

{}