Use After Free

Summary

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, there's 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 "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 freeand 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. FFmpeg versions prior to 8.0 are affected.