CVE-2025-59734

It is possible to cause an use-after-free write in SANM decoding with a carefully crafted animation using subversion <2.

When a STORchunk is present, a subsequent FOBJchunk will be saved in ctx->stored_frame. Stored frames can later be referenced by FTCHchunks. For files using subversion < 2, the undecoded frame is stored, and decoded again when the FTCHchunks are parsed.However, in process_frame_objif the frame has an invalid size, theres an early return, with a value of 0.

This causes the code in decode_frameto still store the raw frame buffer into ctx->stored_frame. Leaving ctx->has_dimensionsset to false.

A subsequent chunk with type FTCHwould call process_ftchand decode that frame obj again, adding to the top/left values and calling process_frame_objagain.
Given that we never set ctx->have_dimensionsbefore, this time we set the dimensions, calling init_buffers, which can reallocate the buffer in ctx->stored_frame, freeing the previous one. However, the GetByteContextobject gbstill holds a reference to the old buffer.




Finally, when the code tries to decode the frame, codecs that accept a GetByteContextas a parameter will trigger a use-after-free read when using gb.

GetByteContextis only used for reading bytes, so at most one could read invalid data. There are no heap allocations between the freeand when the object is accessed. However, upon returning to process_ftch, the code restoresthe original values for top/left in stored_frame, writing 4 bytes to the freed data at offset 6, potentially corrupting the allocators 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.