A 16-byte heap use-after-free read was found in FFmpeg's RASC video decoder (libavcodec/rasc.c), in the decode_move() function.

When processing a MOVE chunk with zlib compression enabled (compression == 1), decode_zlib() decompresses data into the s->delta buffer and a GetByteContext (mc) is initialized pointing into it. During the move-processing loop, a type-0 move entry calls av_fast_padded_malloc(&s->delta, &s->delta_size, w*h*s->bpp), which frees and reallocates the buffer when the requested size (e.g. 1600 bytes for a 20x20 32bpp move) exceeds s->delta_size (134 bytes after the initial inflate). The mc pointer is left dangling, and the next loop iteration performs 7 bytestream2_get_le16(&mc) calls and one bytestream2_skip(&mc, 2), reading 16 bytes total from freed heap memory.

The RASC decoder is enabled by default (CONFIG_RASC_DECODER=yes) and is triggered automatically when demuxing AVI files with the RIFF FourCC ('R','A','S','C'). No special flags or codec selection is needed; user interaction is required to open or play the crafted file.

The proven impact is denial of service (deterministic crash on ASan/hardened-allocator builds). On standard glibc, behavior depends on heap reuse patterns.

Affected: FFmpeg (all versions containing the RASC decoder through current HEAD). The reporter verified on FFmpeg master (commit 78da965).

Fix: PR #22992 by Michael Niedermayer, applied to FFmpeg master. The fix introduces a dedicated scratch buffer (s->mv_scratch) for the type-0 pixel copy so s->delta and mc are not disturbed.
Patch: https://patchwork.ffmpeg.org/project/ffmpeg/patch/177766314111.63.10674887811034989327@29965ddac10e/
Mailing list: https://lists.ffmpeg.org/archives/list/ffmpeg-devel@ffmpeg.org/message/TTRIJZA7UL6KJTEDMMBGZPLLJERJ3EFX/

Reporter: Seung Min Shin (credited as Found-by in the upstream patch)
PSIRT Ticket: PSIRTSUPT-11278