{“lastseen”:””,”description”:”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.”,”published”:”2025-10-06T08:09:44.280Z”,”modified”:”2025-10-06T08:09:44.280Z”,”type”:”cve”,”title”:”Heap-buffer-overflow write in FFmpeg SANM process_ftch”,”source”:”Google”,”references”:”https:\/\/b.corp.google.com\/issues\/440183164″,”id”:”CVE-2025-59734″,”bulletinFamily”:””,”cwe”:[“CWE-416″],”cvelist”:null,”sourceData”:”FFmpeg FFmpeg 4d7c609be37dc57d31527c8c9e5945dc9491a7cd\\nFFmpeg FFmpeg 7.1.1″,”sourceHref”:””,”cvss”:{“score”:8.7,”severity”:”HIGH”,”vector”:”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″},”cvss2″:{},”cvss3″:{“version”:””,”vectorString”:””,”baseScore”:0,”baseSeverity”:””,”attackVector”:””,”attackComplexity”:””,”privilegesRequired”:””,”userInteraction”:””,”scope”:””,”confidentialityImpact”:””,”integrityImpact”:””,”availabilityImpact”:””,”cvssV3″:{“version”:””,”vectorString”:””,”baseScore”:0,”baseSeverity”:””,”attackVector”:””,”attackComplexity”:””,”privilegesRequired”:””,”userInteraction”:””,”scope”:””,”confidentialityImpact”:””,”integrityImpact”:””,”availabilityImpact”:””}},”href”:””,”category_name”:”CVE”,”post_link”:””,”product”:”FFmpeg”,”version”:”4d7c609be37dc57d31527c8c9e5945dc9491a7cd”,”vendor”:”FFmpeg”,”ai_description”:””,”ai_severity”:””,”ai_vendor”:””,”ai_product”:””,”ai_version”:””,”ai_score”:0}<\/p>\n","protected":false},"excerpt":{"rendered":"
{“lastseen”:””,”description”:”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…<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[2],"tags":[6,8,19,12,15,13,7,11,5],"class_list":["post-20330","post","type-post","status-publish","format-standard","hentry","category-category_cve","tag-cve","tag-cvss","tag-cvss-87","tag-exploit","tag-high","tag-news","tag-security","tag-tapic","tag-vulnerability"],"yoast_head":"\n