CVE-2025-59734

Full vulnerability record from the local CVENow database.

Description

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 using subversion < 2, the undecoded frame is stored, and decoded again when the FTCH chunks are parsed. However, in process_frame_obj if the frame has an invalid size, there’s an early return, with a value of 0. This causes the code in decode_frame to still store the raw frame buffer into ctx->stored_frame. Leaving ctx->has_dimensions set to false. A subsequent chunk with type FTCH would call process_ftch and decode that frame obj again, adding to the top/left values and calling process_frame_obj again. Given that we never set ctx->have_dimensions before, this time we set the dimensions, calling init_buffers, which can reallocate the buffer in ctx->stored_frame, freeing the previous one. However, the GetByteContext object gb still holds a reference to the old buffer. Finally, when the code tries to decode the frame, codecs that accept a GetByteContext as a parameter will trigger a use-after-free read when using gb. GetByteContext is only used for reading bytes, so at most one could read invalid data. There are no heap allocations between the free and when the object is accessed. However, upon returning to process_ftch, the code restores the original values for top/left in stored_frame, writing 4 bytes to the freed data at offset 6, potentially corrupting the allocator’s metadata. This issue can be triggered just by probing whether a file has the sanm format. We recommend upgrading to version 8.0 or beyond.

Severity

HIGH

CVSS score

8.7 (v4.0)

Vulnerability status

Deferred

Source identifier

[email protected]

Published

2025-10-06 08:15:35.227000

Last modified

2026-10-19 16:10:00.260000

View original CVE JSON

{
  "id": "CVE-2025-59734",
  "sourceIdentifier": "[email protected]",
  "published": "2025-10-06T08:15:35.227",
  "lastModified": "2026-10-19T16:10:00.260",
  "vulnStatus": "Deferred",
  "cveTags": [],
  "descriptions": [
    {
      "lang": "en",
      "value": "It is possible to cause an use-after-free write in SANM decoding with a carefully crafted animation using subversion <2.\n\nWhen 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 using subversion < 2, the undecoded frame is stored, and decoded again when the FTCH chunks are parsed. However, in process_frame_obj if the frame has an invalid size, there’s an early return, with a value of 0. \n\nThis causes the code in decode_frame to still store the raw frame buffer into ctx->stored_frame. Leaving ctx->has_dimensions set to false.\n\nA subsequent chunk with type FTCH would call process_ftch and decode that frame obj again, adding to the top/left values and calling process_frame_obj again.\nGiven that we never set ctx->have_dimensions before, this time we set the dimensions, calling init_buffers, which can reallocate the buffer in ctx->stored_frame, freeing the previous one. However, the GetByteContext object gb still holds a reference to the old buffer.\n\n\n\n\nFinally, when the code tries to decode the frame, codecs that accept a GetByteContext as a parameter will trigger a use-after-free read when using gb.\n\nGetByteContext is only used for reading bytes, so at most one could read invalid data. There are no heap allocations between the free and when the object is accessed. However, upon returning to process_ftch, the code restores the original values for top/left in stored_frame, writing 4 bytes to the freed data at offset 6, potentially corrupting the allocator’s metadata.\n\nThis issue can be triggered just by probing whether a file has the sanm format.\n\n\n\n\n\n\n\nWe recommend upgrading to version 8.0 or beyond."
    },
    {
      "lang": "es",
      "value": "Es posible causar una escritura de uso después de liberación en la decodificación SANM con una animación cuidadosamente diseñada usando subversión <2.\n\nCuando un chunk STOR está presente, un chunk FOBJ subsiguiente se guardará en ctx -> stored_frame. Los frames almacenados pueden ser referenciados más tarde por chunks FTCH. Para archivos que usan subversión < 2, el frame sin decodificar se almacena y se decodifica de nuevo cuando se analizan los chunks FTCH. Sin embargo, en process_frame_obj, si el frame tiene un tamaño inválido, hay un retorno anticipado, con un valor de 0.\n\nEsto provoca que el código en decode_frame siga almacenando el búfer de frame en bruto en ctx -> stored_frame. Dejando ctx -> has_dimensions establecido en falso.\n\nUn chunk subsiguiente de tipo FTCH llamaría a process_ftch y decodificaría ese objeto de frame de nuevo, añadiendo a los valores superior/izquierdo y llamando a process_frame_obj de nuevo.\nDado que nunca establecimos ctx -> have_dimensions antes, esta vez establecemos las dimensiones, llamando a init_buffers, lo que puede reasignar el búfer en ctx -> stored_frame, liberando el anterior. Sin embargo, el objeto GetByteContext gb todavía mantiene una referencia al búfer antiguo.\n\nFinalmente, cuando el código intenta decodificar el frame, los códecs que aceptan un GetByteContext como parámetro activarán una lectura de uso después de liberación al usar gb.\n\nGetByteContext solo se usa para leer bytes, por lo que, como máximo, se podrían leer datos inválidos. No hay asignaciones de heap entre la liberación y el momento en que se accede al objeto. Sin embargo, al regresar a process_ftch, el código restaura los valores originales para superior/izquierdo en stored_frame, escribiendo 4 bytes en los datos liberados en el desplazamiento 6, potencialmente corrompiendo los metadatos del asignador.\n\nEste problema puede ser activado simplemente al sondear si un archivo tiene el formato sanm.\n\nRecomendamos actualizar a la versión 8.0 o posterior."
    }
  ],
  "affected": [
    {
      "source": "[email protected]",
      "affectedData": [
        {
          "vendor": "FFmpeg",
          "product": "FFmpeg",
          "defaultStatus": "unaffected",
          "collectionURL": "https://git.ffmpeg.org/ffmpeg.git",
          "packageName": "SANM",
          "repo": "https://git.ffmpeg.org/ffmpeg.git",
          "versions": [
            {
              "version": "4d7c609be37dc57d31527c8c9e5945dc9491a7cd",
              "lessThan": "8.0",
              "versionType": "custom",
              "status": "affected"
            },
            {
              "version": "7.1.1",
              "lessThan": "8.0",
              "versionType": "semver",
              "status": "affected"
            }
          ]
        }
      ]
    }
  ],
  "metrics": {
    "cvssMetricV40": [
      {
        "source": "[email protected]",
        "type": "Secondary",
        "cvssData": {
          "version": "4.0",
          "vectorString": "CVSS:4.0/AV:A/AC:H/AT:N/PR:N/UI:P/VC:H/VI:H/VA:N/SC:H/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",
          "baseScore": 8.7,
          "baseSeverity": "HIGH",
          "attackVector": "ADJACENT",
          "attackComplexity": "HIGH",
          "attackRequirements": "NONE",
          "privilegesRequired": "NONE",
          "userInteraction": "PASSIVE",
          "vulnConfidentialityImpact": "HIGH",
          "vulnIntegrityImpact": "HIGH",
          "vulnAvailabilityImpact": "NONE",
          "subConfidentialityImpact": "HIGH",
          "subIntegrityImpact": "HIGH",
          "subAvailabilityImpact": "NONE",
          "exploitMaturity": "NOT_DEFINED",
          "confidentialityRequirement": "NOT_DEFINED",
          "integrityRequirement": "NOT_DEFINED",
          "availabilityRequirement": "NOT_DEFINED",
          "modifiedAttackVector": "NOT_DEFINED",
          "modifiedAttackComplexity": "NOT_DEFINED",
          "modifiedAttackRequirements": "NOT_DEFINED",
          "modifiedPrivilegesRequired": "NOT_DEFINED",
          "modifiedUserInteraction": "NOT_DEFINED",
          "modifiedVulnConfidentialityImpact": "NOT_DEFINED",
          "modifiedVulnIntegrityImpact": "NOT_DEFINED",
          "modifiedVulnAvailabilityImpact": "NOT_DEFINED",
          "modifiedSubConfidentialityImpact": "NOT_DEFINED",
          "modifiedSubIntegrityImpact": "NOT_DEFINED",
          "modifiedSubAvailabilityImpact": "NOT_DEFINED",
          "Safety": "NOT_DEFINED",
          "Automatable": "NOT_DEFINED",
          "Recovery": "NOT_DEFINED",
          "valueDensity": "NOT_DEFINED",
          "vulnerabilityResponseEffort": "NOT_DEFINED",
          "providerUrgency": "NOT_DEFINED"
        }
      }
    ],
    "ssvcV203": [
      {
        "source": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
        "ssvcData": {
          "timestamp": "2025-10-08T03:55:15.823380Z",
          "id": "CVE-2025-59734",
          "options": [
            {
              "exploitation": "none"
            },
            {
              "automatable": "no"
            },
            {
              "technicalImpact": "total"
            }
          ],
          "role": "CISA Coordinator",
          "version": "2.0.3"
        }
      }
    ]
  },
  "weaknesses": [
    {
      "source": "[email protected]",
      "type": "Secondary",
      "description": [
        {
          "lang": "en",
          "value": "CWE-416"
        }
      ]
    }
  ],
  "references": [
    {
      "url": "https://issuetracker.google.com/440183164",
      "source": "[email protected]"
    }
  ]
}