CVE-2025-59734 (GCVE-0-2025-59734)
Vulnerability from cvelistv5
Published
2025-10-06 08:09
Modified
2025-10-19 14:51
Severity ?
8.7 (High) - 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
CWE
Summary
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.
References
Impacted products
Vendor Product Version
FFmpeg FFmpeg Version: 4d7c609be37dc57d31527c8c9e5945dc9491a7cd   < 8.0
Version: 7.1.1   ≤
Create a notification for this product.
Show details on NVD website

To clipboard 

{
  "containers": {
    "adp": [
      {
        "metrics": [
          {
            "other": {
              "content": {
                "id": "CVE-2025-59734",
                "options": [
                  {
                    "Exploitation": "none"
                  },
                  {
                    "Automatable": "no"
                  },
                  {
                    "Technical Impact": "total"
                  }
                ],
                "role": "CISA Coordinator",
                "timestamp": "2025-10-07T00:00:00+00:00",
                "version": "2.0.3"
              },
              "type": "ssvc"
            }
          }
        ],
        "providerMetadata": {
          "dateUpdated": "2025-10-08T03:55:14.843Z",
          "orgId": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
          "shortName": "CISA-ADP"
        },
        "title": "CISA ADP Vulnrichment"
      }
    ],
    "cna": {
      "affected": [
        {
          "collectionURL": "https://git.ffmpeg.org/ffmpeg.git",
          "defaultStatus": "unaffected",
          "packageName": "SANM",
          "product": "FFmpeg",
          "repo": "https://git.ffmpeg.org/ffmpeg.git",
          "vendor": "FFmpeg",
          "versions": [
            {
              "lessThan": "8.0",
              "status": "affected",
              "version": "4d7c609be37dc57d31527c8c9e5945dc9491a7cd",
              "versionType": "custom"
            },
            {
              "lessThan": "8.0",
              "status": "affected",
              "version": "7.1.1",
              "versionType": "semver"
            }
          ]
        }
      ],
      "credits": [
        {
          "lang": "en",
          "type": "finder",
          "value": "Google Big Sleep"
        }
      ],
      "datePublic": "2025-08-20T22:00:00.000Z",
      "descriptions": [
        {
          "lang": "en",
          "supportingMedia": [
            {
              "base64": false,
              "type": "text/html",
              "value": "\u003cp\u003e\u003c/p\u003e\u003cp\u003e\u003c/p\u003e\u003cp\u003e\u003c/p\u003e\u003cp\u003e\u003c/p\u003e\u003cp\u003e\u003c/p\u003e\u003cp\u003eIt is possible to cause an use-after-free write in SANM decoding with a carefully crafted animation using subversion \u0026lt;2.\u003c/p\u003e\u003cp\u003eWhen a \u003ccode\u003eSTOR\u003c/code\u003e\u0026nbsp;chunk is present, a subsequent \u003ccode\u003eFOBJ\u003c/code\u003e\u0026nbsp;chunk will be saved in \u003ccode\u003ectx-\u0026gt;stored_frame\u003c/code\u003e. Stored frames can later be referenced by \u003ccode\u003eFTCH\u003c/code\u003e\u0026nbsp;chunks. For files using subversion \u0026lt; 2, the undecoded frame is stored, and decoded again when the \u003ccode\u003eFTCH\u003c/code\u003e\u0026nbsp;chunks are parsed.\u0026nbsp;\u003cspan style=\"background-color: rgb(255, 255, 255);\"\u003eHowever, in \u003c/span\u003e\u003ccode\u003eprocess_frame_obj\u003c/code\u003e\u003cspan style=\"background-color: rgb(255, 255, 255);\"\u003e\u0026nbsp;if the frame has an invalid size, there\u2019s an early return, with a value of 0.\u0026nbsp;\u003c/span\u003e\u003c/p\u003e\u003cp\u003eThis causes the code in \u003ccode\u003edecode_frame\u003c/code\u003e\u0026nbsp;to still store the raw frame buffer into \u003ccode\u003ectx-\u0026gt;stored_frame\u003c/code\u003e. Leaving \u003ccode\u003ectx-\u0026gt;has_dimensions\u003c/code\u003e\u0026nbsp;set to \u003ccode\u003efalse\u003c/code\u003e.\u003c/p\u003e\u003cp\u003eA subsequent chunk with type \u003ccode\u003eFTCH\u003c/code\u003e\u0026nbsp;would call \u003ccode\u003eprocess_ftch\u003c/code\u003e\u0026nbsp;and decode that frame obj again, adding to the top/left values and calling \u003ccode\u003eprocess_frame_obj\u003c/code\u003e\u0026nbsp;again.\u003cbr\u003e\u003cspan style=\"background-color: rgb(255, 255, 255);\"\u003eGiven that we never set \u003c/span\u003e\u003ccode\u003ectx-\u0026gt;have_dimensions\u003c/code\u003e\u003cspan style=\"background-color: rgb(255, 255, 255);\"\u003e\u0026nbsp;before, this time we set the dimensions, calling \u003c/span\u003e\u003ccode\u003einit_buffers\u003c/code\u003e\u003cspan style=\"background-color: rgb(255, 255, 255);\"\u003e, which can reallocate the buffer in \u003c/span\u003e\u003ccode\u003ectx-\u0026gt;stored_frame\u003c/code\u003e\u003cspan style=\"background-color: rgb(255, 255, 255);\"\u003e, freeing the previous one. However, the \u003c/span\u003e\u003ccode\u003eGetByteContext\u003c/code\u003e\u003cspan style=\"background-color: rgb(255, 255, 255);\"\u003e\u0026nbsp;object \u003c/span\u003e\u003ccode\u003egb\u003c/code\u003e\u003cspan style=\"background-color: rgb(255, 255, 255);\"\u003e\u0026nbsp;still holds a reference to the old buffer.\u003c/span\u003e\u003cbr\u003e\u003c/p\u003e\u003cp\u003e\u003c/p\u003e\u003cp\u003eFinally, when the code tries to decode the frame, codecs that accept a \u003ccode\u003eGetByteContext\u003c/code\u003e\u0026nbsp;as a parameter will trigger a use-after-free read when using \u003ccode\u003egb\u003c/code\u003e.\u003c/p\u003e\u003cp\u003e\u003ccode\u003eGetByteContext\u003c/code\u003e\u0026nbsp;is only used for reading bytes, so at most one could read invalid data. There are no heap allocations between the \u003ccode\u003efree\u003c/code\u003e\u0026nbsp;and when the object is accessed. However, upon returning to \u003ccode\u003eprocess_ftch\u003c/code\u003e, the code \u003cem\u003erestores\u003c/em\u003e\u0026nbsp;the original values for top/left in \u003ccode\u003estored_frame\u003c/code\u003e, writing 4 bytes to the freed data at offset 6, potentially corrupting the allocator\u2019s metadata.\u003c/p\u003e\u003cp\u003eThis issue can be triggered just by probing whether a file has the sanm format.\u003c/p\u003e\u003cp\u003e\u003c/p\u003e\u003cp\u003e\u003c/p\u003e\u003cp\u003e\u003c/p\u003eWe recommend upgrading to version 8.0 or beyond.\u003cp\u003e\u003c/p\u003e\u003cbr\u003e"
            }
          ],
          "value": "It is possible to cause an use-after-free write in SANM decoding with a carefully crafted animation using subversion \u003c2.\n\nWhen a STOR\u00a0chunk is present, a subsequent FOBJ\u00a0chunk will be saved in ctx-\u003estored_frame. Stored frames can later be referenced by FTCH\u00a0chunks. For files using subversion \u003c 2, the undecoded frame is stored, and decoded again when the FTCH\u00a0chunks are parsed.\u00a0However, in process_frame_obj\u00a0if the frame has an invalid size, there\u2019s an early return, with a value of 0.\u00a0\n\nThis causes the code in decode_frame\u00a0to still store the raw frame buffer into ctx-\u003estored_frame. Leaving ctx-\u003ehas_dimensions\u00a0set to false.\n\nA subsequent chunk with type FTCH\u00a0would call process_ftch\u00a0and decode that frame obj again, adding to the top/left values and calling process_frame_obj\u00a0again.\nGiven that we never set ctx-\u003ehave_dimensions\u00a0before, this time we set the dimensions, calling init_buffers, which can reallocate the buffer in ctx-\u003estored_frame, freeing the previous one. However, the GetByteContext\u00a0object gb\u00a0still 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\u00a0as a parameter will trigger a use-after-free read when using gb.\n\nGetByteContext\u00a0is only used for reading bytes, so at most one could read invalid data. There are no heap allocations between the free\u00a0and when the object is accessed. However, upon returning to process_ftch, the code restores\u00a0the original values for top/left in stored_frame, writing 4 bytes to the freed data at offset 6, potentially corrupting the allocator\u2019s 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."
        }
      ],
      "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": "NONE",
            "attackVector": "ADJACENT",
            "baseScore": 8.7,
            "baseSeverity": "HIGH",
            "privilegesRequired": "NONE",
            "providerUrgency": "NOT_DEFINED",
            "subAvailabilityImpact": "NONE",
            "subConfidentialityImpact": "HIGH",
            "subIntegrityImpact": "HIGH",
            "userInteraction": "PASSIVE",
            "valueDensity": "NOT_DEFINED",
            "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",
            "version": "4.0",
            "vulnAvailabilityImpact": "NONE",
            "vulnConfidentialityImpact": "HIGH",
            "vulnIntegrityImpact": "HIGH",
            "vulnerabilityResponseEffort": "NOT_DEFINED"
          },
          "format": "CVSS",
          "scenarios": [
            {
              "lang": "en",
              "value": "GENERAL"
            }
          ]
        }
      ],
      "problemTypes": [
        {
          "descriptions": [
            {
              "cweId": "CWE-416",
              "description": "CWE-416 Use After Free",
              "lang": "en",
              "type": "CWE"
            }
          ]
        }
      ],
      "providerMetadata": {
        "dateUpdated": "2025-10-19T14:51:43.143Z",
        "orgId": "14ed7db2-1595-443d-9d34-6215bf890778",
        "shortName": "Google"
      },
      "references": [
        {
          "url": "https://issuetracker.google.com/440183164"
        }
      ],
      "source": {
        "discovery": "EXTERNAL"
      },
      "title": "Heap-buffer-overflow write in FFmpeg SANM process_ftch",
      "x_generator": {
        "engine": "Vulnogram 0.2.0"
      }
    }
  },
  "cveMetadata": {
    "assignerOrgId": "14ed7db2-1595-443d-9d34-6215bf890778",
    "assignerShortName": "Google",
    "cveId": "CVE-2025-59734",
    "datePublished": "2025-10-06T08:09:44.280Z",
    "dateReserved": "2025-09-19T08:11:37.550Z",
    "dateUpdated": "2025-10-19T14:51:43.143Z",
    "state": "PUBLISHED"
  },
  "dataType": "CVE_RECORD",
  "dataVersion": "5.1",
  "vulnerability-lookup:meta": {
    "nvd": "{\"cve\":{\"id\":\"CVE-2025-59734\",\"sourceIdentifier\":\"cve-coordination@google.com\",\"published\":\"2025-10-06T08:15:35.227\",\"lastModified\":\"2025-10-19T15:15:39.000\",\"vulnStatus\":\"Awaiting Analysis\",\"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 \u003c2.\\n\\nWhen a STOR\u00a0chunk is present, a subsequent FOBJ\u00a0chunk will be saved in ctx-\u003estored_frame. Stored frames can later be referenced by FTCH\u00a0chunks. For files using subversion \u003c 2, the undecoded frame is stored, and decoded again when the FTCH\u00a0chunks are parsed.\u00a0However, in process_frame_obj\u00a0if the frame has an invalid size, there\u2019s an early return, with a value of 0.\u00a0\\n\\nThis causes the code in decode_frame\u00a0to still store the raw frame buffer into ctx-\u003estored_frame. Leaving ctx-\u003ehas_dimensions\u00a0set to false.\\n\\nA subsequent chunk with type FTCH\u00a0would call process_ftch\u00a0and decode that frame obj again, adding to the top/left values and calling process_frame_obj\u00a0again.\\nGiven that we never set ctx-\u003ehave_dimensions\u00a0before, this time we set the dimensions, calling init_buffers, which can reallocate the buffer in ctx-\u003estored_frame, freeing the previous one. However, the GetByteContext\u00a0object gb\u00a0still 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\u00a0as a parameter will trigger a use-after-free read when using gb.\\n\\nGetByteContext\u00a0is only used for reading bytes, so at most one could read invalid data. There are no heap allocations between the free\u00a0and when the object is accessed. However, upon returning to process_ftch, the code restores\u00a0the original values for top/left in stored_frame, writing 4 bytes to the freed data at offset 6, potentially corrupting the allocator\u2019s 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.\"}],\"metrics\":{\"cvssMetricV40\":[{\"source\":\"cve-coordination@google.com\",\"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\"}}]},\"weaknesses\":[{\"source\":\"cve-coordination@google.com\",\"type\":\"Secondary\",\"description\":[{\"lang\":\"en\",\"value\":\"CWE-416\"}]}],\"references\":[{\"url\":\"https://issuetracker.google.com/440183164\",\"source\":\"cve-coordination@google.com\"}]}}",
    "vulnrichment": {
      "containers": "{\"adp\": [{\"title\": \"CISA ADP Vulnrichment\", \"metrics\": [{\"other\": {\"type\": \"ssvc\", \"content\": {\"id\": \"CVE-2025-59734\", \"role\": \"CISA Coordinator\", \"options\": [{\"Exploitation\": \"none\"}, {\"Automatable\": \"no\"}, {\"Technical Impact\": \"total\"}], \"version\": \"2.0.3\", \"timestamp\": \"2025-10-06T15:17:08.741346Z\"}}}], \"providerMetadata\": {\"orgId\": \"134c704f-9b21-4f2e-91b3-4a467353bcc0\", \"shortName\": \"CISA-ADP\", \"dateUpdated\": \"2025-10-06T15:19:41.012Z\"}}], \"cna\": {\"title\": \"Heap-buffer-overflow write in FFmpeg SANM process_ftch\", \"source\": {\"discovery\": \"EXTERNAL\"}, \"credits\": [{\"lang\": \"en\", \"type\": \"finder\", \"value\": \"Google Big Sleep\"}], \"impacts\": [{\"capecId\": \"CAPEC-100\", \"descriptions\": [{\"lang\": \"en\", \"value\": \"CAPEC-100 Overflow Buffers\"}]}], \"metrics\": [{\"format\": \"CVSS\", \"cvssV4_0\": {\"Safety\": \"NOT_DEFINED\", \"version\": \"4.0\", \"Recovery\": \"NOT_DEFINED\", \"baseScore\": 8.7, \"Automatable\": \"NOT_DEFINED\", \"attackVector\": \"ADJACENT\", \"baseSeverity\": \"HIGH\", \"valueDensity\": \"NOT_DEFINED\", \"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\", \"providerUrgency\": \"NOT_DEFINED\", \"userInteraction\": \"PASSIVE\", \"attackComplexity\": \"HIGH\", \"attackRequirements\": \"NONE\", \"privilegesRequired\": \"NONE\", \"subIntegrityImpact\": \"HIGH\", \"vulnIntegrityImpact\": \"HIGH\", \"subAvailabilityImpact\": \"NONE\", \"vulnAvailabilityImpact\": \"NONE\", \"subConfidentialityImpact\": \"HIGH\", \"vulnConfidentialityImpact\": \"HIGH\", \"vulnerabilityResponseEffort\": \"NOT_DEFINED\"}, \"scenarios\": [{\"lang\": \"en\", \"value\": \"GENERAL\"}]}], \"affected\": [{\"repo\": \"https://git.ffmpeg.org/ffmpeg.git\", \"vendor\": \"FFmpeg\", \"product\": \"FFmpeg\", \"versions\": [{\"status\": \"affected\", \"version\": \"4d7c609be37dc57d31527c8c9e5945dc9491a7cd\", \"lessThan\": \"8.0\", \"versionType\": \"custom\"}, {\"status\": \"affected\", \"version\": \"7.1.1\", \"lessThan\": \"8.0\", \"versionType\": \"semver\"}], \"packageName\": \"SANM\", \"collectionURL\": \"https://git.ffmpeg.org/ffmpeg.git\", \"defaultStatus\": \"unaffected\"}], \"datePublic\": \"2025-08-20T22:00:00.000Z\", \"references\": [{\"url\": \"https://issuetracker.google.com/440183164\"}], \"x_generator\": {\"engine\": \"Vulnogram 0.2.0\"}, \"descriptions\": [{\"lang\": \"en\", \"value\": \"It is possible to cause an use-after-free write in SANM decoding with a carefully crafted animation using subversion \u003c2.\\n\\nWhen a STOR\\u00a0chunk is present, a subsequent FOBJ\\u00a0chunk will be saved in ctx-\u003estored_frame. Stored frames can later be referenced by FTCH\\u00a0chunks. For files using subversion \u003c 2, the undecoded frame is stored, and decoded again when the FTCH\\u00a0chunks are parsed.\\u00a0However, in process_frame_obj\\u00a0if the frame has an invalid size, there\\u2019s an early return, with a value of 0.\\u00a0\\n\\nThis causes the code in decode_frame\\u00a0to still store the raw frame buffer into ctx-\u003estored_frame. Leaving ctx-\u003ehas_dimensions\\u00a0set to false.\\n\\nA subsequent chunk with type FTCH\\u00a0would call process_ftch\\u00a0and decode that frame obj again, adding to the top/left values and calling process_frame_obj\\u00a0again.\\nGiven that we never set ctx-\u003ehave_dimensions\\u00a0before, this time we set the dimensions, calling init_buffers, which can reallocate the buffer in ctx-\u003estored_frame, freeing the previous one. However, the GetByteContext\\u00a0object gb\\u00a0still 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\\u00a0as a parameter will trigger a use-after-free read when using gb.\\n\\nGetByteContext\\u00a0is only used for reading bytes, so at most one could read invalid data. There are no heap allocations between the free\\u00a0and when the object is accessed. However, upon returning to process_ftch, the code restores\\u00a0the original values for top/left in stored_frame, writing 4 bytes to the freed data at offset 6, potentially corrupting the allocator\\u2019s 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.\", \"supportingMedia\": [{\"type\": \"text/html\", \"value\": \"\u003cp\u003e\u003c/p\u003e\u003cp\u003e\u003c/p\u003e\u003cp\u003e\u003c/p\u003e\u003cp\u003e\u003c/p\u003e\u003cp\u003e\u003c/p\u003e\u003cp\u003eIt is possible to cause an use-after-free write in SANM decoding with a carefully crafted animation using subversion \u0026lt;2.\u003c/p\u003e\u003cp\u003eWhen a \u003ccode\u003eSTOR\u003c/code\u003e\u0026nbsp;chunk is present, a subsequent \u003ccode\u003eFOBJ\u003c/code\u003e\u0026nbsp;chunk will be saved in \u003ccode\u003ectx-\u0026gt;stored_frame\u003c/code\u003e. Stored frames can later be referenced by \u003ccode\u003eFTCH\u003c/code\u003e\u0026nbsp;chunks. For files using subversion \u0026lt; 2, the undecoded frame is stored, and decoded again when the \u003ccode\u003eFTCH\u003c/code\u003e\u0026nbsp;chunks are parsed.\u0026nbsp;\u003cspan style=\\\"background-color: rgb(255, 255, 255);\\\"\u003eHowever, in \u003c/span\u003e\u003ccode\u003eprocess_frame_obj\u003c/code\u003e\u003cspan style=\\\"background-color: rgb(255, 255, 255);\\\"\u003e\u0026nbsp;if the frame has an invalid size, there\\u2019s an early return, with a value of 0.\u0026nbsp;\u003c/span\u003e\u003c/p\u003e\u003cp\u003eThis causes the code in \u003ccode\u003edecode_frame\u003c/code\u003e\u0026nbsp;to still store the raw frame buffer into \u003ccode\u003ectx-\u0026gt;stored_frame\u003c/code\u003e. Leaving \u003ccode\u003ectx-\u0026gt;has_dimensions\u003c/code\u003e\u0026nbsp;set to \u003ccode\u003efalse\u003c/code\u003e.\u003c/p\u003e\u003cp\u003eA subsequent chunk with type \u003ccode\u003eFTCH\u003c/code\u003e\u0026nbsp;would call \u003ccode\u003eprocess_ftch\u003c/code\u003e\u0026nbsp;and decode that frame obj again, adding to the top/left values and calling \u003ccode\u003eprocess_frame_obj\u003c/code\u003e\u0026nbsp;again.\u003cbr\u003e\u003cspan style=\\\"background-color: rgb(255, 255, 255);\\\"\u003eGiven that we never set \u003c/span\u003e\u003ccode\u003ectx-\u0026gt;have_dimensions\u003c/code\u003e\u003cspan style=\\\"background-color: rgb(255, 255, 255);\\\"\u003e\u0026nbsp;before, this time we set the dimensions, calling \u003c/span\u003e\u003ccode\u003einit_buffers\u003c/code\u003e\u003cspan style=\\\"background-color: rgb(255, 255, 255);\\\"\u003e, which can reallocate the buffer in \u003c/span\u003e\u003ccode\u003ectx-\u0026gt;stored_frame\u003c/code\u003e\u003cspan style=\\\"background-color: rgb(255, 255, 255);\\\"\u003e, freeing the previous one. However, the \u003c/span\u003e\u003ccode\u003eGetByteContext\u003c/code\u003e\u003cspan style=\\\"background-color: rgb(255, 255, 255);\\\"\u003e\u0026nbsp;object \u003c/span\u003e\u003ccode\u003egb\u003c/code\u003e\u003cspan style=\\\"background-color: rgb(255, 255, 255);\\\"\u003e\u0026nbsp;still holds a reference to the old buffer.\u003c/span\u003e\u003cbr\u003e\u003c/p\u003e\u003cp\u003e\u003c/p\u003e\u003cp\u003eFinally, when the code tries to decode the frame, codecs that accept a \u003ccode\u003eGetByteContext\u003c/code\u003e\u0026nbsp;as a parameter will trigger a use-after-free read when using \u003ccode\u003egb\u003c/code\u003e.\u003c/p\u003e\u003cp\u003e\u003ccode\u003eGetByteContext\u003c/code\u003e\u0026nbsp;is only used for reading bytes, so at most one could read invalid data. There are no heap allocations between the \u003ccode\u003efree\u003c/code\u003e\u0026nbsp;and when the object is accessed. However, upon returning to \u003ccode\u003eprocess_ftch\u003c/code\u003e, the code \u003cem\u003erestores\u003c/em\u003e\u0026nbsp;the original values for top/left in \u003ccode\u003estored_frame\u003c/code\u003e, writing 4 bytes to the freed data at offset 6, potentially corrupting the allocator\\u2019s metadata.\u003c/p\u003e\u003cp\u003eThis issue can be triggered just by probing whether a file has the sanm format.\u003c/p\u003e\u003cp\u003e\u003c/p\u003e\u003cp\u003e\u003c/p\u003e\u003cp\u003e\u003c/p\u003eWe recommend upgrading to version 8.0 or beyond.\u003cp\u003e\u003c/p\u003e\u003cbr\u003e\", \"base64\": false}]}], \"problemTypes\": [{\"descriptions\": [{\"lang\": \"en\", \"type\": \"CWE\", \"cweId\": \"CWE-416\", \"description\": \"CWE-416 Use After Free\"}]}], \"providerMetadata\": {\"orgId\": \"14ed7db2-1595-443d-9d34-6215bf890778\", \"shortName\": \"Google\", \"dateUpdated\": \"2025-10-19T14:51:43.143Z\"}}}",
      "cveMetadata": "{\"cveId\": \"CVE-2025-59734\", \"state\": \"PUBLISHED\", \"dateUpdated\": \"2025-10-19T14:51:43.143Z\", \"dateReserved\": \"2025-09-19T08:11:37.550Z\", \"assignerOrgId\": \"14ed7db2-1595-443d-9d34-6215bf890778\", \"datePublished\": \"2025-10-06T08:09:44.280Z\", \"assignerShortName\": \"Google\"}",
      "dataType": "CVE_RECORD",
      "dataVersion": "5.1"
    }
  }
}


Log in or create an account to share your comment.




Tags
Taxonomy of the tags.




Sightings

Author Source Type Date

Nomenclature

  • Seen: The vulnerability was mentioned, discussed, or seen somewhere by the user.
  • Confirmed: The vulnerability is confirmed from an analyst perspective.
  • Published Proof of Concept: A public proof of concept is available for this vulnerability.
  • Exploited: This vulnerability was exploited and seen by the user reporting the sighting.
  • Patched: This vulnerability was successfully patched by the user reporting the sighting.
  • Not exploited: This vulnerability was not exploited or seen by the user reporting the sighting.
  • Not confirmed: The user expresses doubt about the veracity of the vulnerability.
  • Not patched: This vulnerability was not successfully patched by the user reporting the sighting.