« Volver al listado

CVE-2025-59729

Estado: AplazadaMedia (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.

Leer descripción completaMostrar menos

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.

CVSS

Probabilidad de explotación (EPSS)

EPSS (Exploit Prediction Scoring System, de FIRST) estima la probabilidad de que una vulnerabilidad sea explotada en 30 días. Complementa a CVSS (impacto) y a CISA KEV (explotación confirmada).

Tecnologías afectadas (2)

⚠ Inferidas por IA a partir de la descripción — NVD aún no ha analizado esta CVE; no son CPE verificados.

Ffmpeg — FfmpegAILibav — LibavAI

CWE

Referencias

JSON original (NVD)

Mostrar
{
  "id": "CVE-2025-59729",
  "cveTags": [],
  "metrics": {
    "ssvcV203": [
      {
        "source": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
        "ssvcData": {
          "id": "CVE-2025-59729",
          "role": "CISA Coordinator",
          "options": [
            {
              "exploitation": "none"
            },
            {
              "automatable": "no"
            },
            {
              "technicalImpact": "partial"
            }
          ],
          "version": "2.0.3",
          "timestamp": "2025-10-06T16:25:07.013593Z"
        }
      }
    ],
    "cvssMetricV40": [
      {
        "type": "Secondary",
        "source": "cve-coordination@google.com",
        "cvssData": {
          "Safety": "NOT_DEFINED",
          "version": "4.0",
          "Recovery": "NOT_DEFINED",
          "baseScore": 5.7,
          "Automatable": "NOT_DEFINED",
          "attackVector": "ADJACENT",
          "baseSeverity": "MEDIUM",
          "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",
          "exploitMaturity": "NOT_DEFINED",
          "providerUrgency": "NOT_DEFINED",
          "userInteraction": "PASSIVE",
          "attackComplexity": "HIGH",
          "attackRequirements": "PRESENT",
          "privilegesRequired": "LOW",
          "subIntegrityImpact": "HIGH",
          "vulnIntegrityImpact": "HIGH",
          "integrityRequirement": "NOT_DEFINED",
          "modifiedAttackVector": "NOT_DEFINED",
          "subAvailabilityImpact": "NONE",
          "vulnAvailabilityImpact": "NONE",
          "availabilityRequirement": "NOT_DEFINED",
          "modifiedUserInteraction": "NOT_DEFINED",
          "modifiedAttackComplexity": "NOT_DEFINED",
          "subConfidentialityImpact": "LOW",
          "vulnConfidentialityImpact": "LOW",
          "confidentialityRequirement": "NOT_DEFINED",
          "modifiedAttackRequirements": "NOT_DEFINED",
          "modifiedPrivilegesRequired": "NOT_DEFINED",
          "modifiedSubIntegrityImpact": "NOT_DEFINED",
          "modifiedVulnIntegrityImpact": "NOT_DEFINED",
          "vulnerabilityResponseEffort": "NOT_DEFINED",
          "modifiedSubAvailabilityImpact": "NOT_DEFINED",
          "modifiedVulnAvailabilityImpact": "NOT_DEFINED",
          "modifiedSubConfidentialityImpact": "NOT_DEFINED",
          "modifiedVulnConfidentialityImpact": "NOT_DEFINED"
        }
      }
    ]
  },
  "affected": [
    {
      "source": "cve-coordination@google.com",
      "affectedData": [
        {
          "repo": "https://git.ffmpeg.org/ffmpeg.git",
          "vendor": "FFmpeg",
          "modules": [
            "get_duration"
          ],
          "product": "FFmpeg",
          "versions": [
            {
              "status": "affected",
              "version": "a218cafe4d3be005ab0c61130f90db4d21afb5db",
              "lessThan": "8.0",
              "versionType": "custom"
            }
          ],
          "packageName": "DHAV",
          "collectionURL": "https://git.ffmpeg.org/ffmpeg.git",
          "defaultStatus": "unaffected"
        }
      ]
    }
  ],
  "published": "2025-10-06T08:15:34.447",
  "references": [
    {
      "url": "https://issuetracker.google.com/433513232",
      "source": "cve-coordination@google.com"
    }
  ],
  "vulnStatus": "Deferred",
  "weaknesses": [
    {
      "type": "Secondary",
      "source": "cve-coordination@google.com",
      "description": [
        {
          "lang": "en",
          "value": "CWE-787"
        }
      ]
    }
  ],
  "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 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.\n\nThe 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.\n\nThere 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.\n\nWe recommend upgrading to version 8.0 or beyond."
    }
  ],
  "lastModified": "2026-06-17T09:46:36.340",
  "sourceIdentifier": "cve-coordination@google.com"
}