CVE-2026-12706: 
Ffmpeg Analyse et atténuation des vulnérabilités

CVE-2026-12706 is a heap use-after-free vulnerability in FFmpeg's RASC video decoder (libavcodec/rasc.c) that can cause a denial of service when a user opens a specially crafted AVI file. The flaw was reported by Seung Min Shin, disclosed on June 19, 2026, and affects all FFmpeg versions containing the RASC decoder through the current HEAD at the time of disclosure (verified on commit 78da965). A patch (PR #22992 by Michael Niedermayer) has been applied to FFmpeg master. It carries a CVSS v3.1 base score of 6.5 (Medium) (GitHub Advisory, Red Hat Bugzilla).

The root cause is a use-after-free (CWE-416) in the decode_move() function within FFmpeg's RASC decoder. 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 triggers av_fast_padded_malloc(&s->delta, &s->delta_size, w*h*s->bpp), which frees and reallocates the buffer when the requested size exceeds s->delta_size; the mc pointer is left dangling. The next loop iteration then 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'), requiring no special flags — only user interaction to open the file (Red Hat Bugzilla, GitHub Advisory).

The primary confirmed impact is denial of service — a deterministic crash on ASan/hardened-allocator builds when the decoder reads 16 bytes from freed heap memory. On standard glibc systems, behavior depends on heap reuse patterns and may result in a crash or undefined behavior. There is no evidence of confidentiality or integrity impact; the CVSS score reflects high availability impact with no confidentiality or integrity loss (Red Hat Bugzilla, GitHub Advisory).

1. Craft malicious AVI file: Create an AVI file with the RIFF FourCC ('R','A','S','C') that contains a RASC video stream with a MOVE chunk using zlib compression (compression == 1).
2. Trigger buffer size mismatch: Within the MOVE chunk, include a type-0 move entry whose pixel dimensions (e.g., 20x20 at 32bpp = 1600 bytes) exceed the initial s->delta buffer size after zlib inflation (e.g., 134 bytes), forcing av_fast_padded_malloc to reallocate the buffer.
3. Deliver the file: Distribute the crafted AVI file to a target via email attachment, web download, or network share — any vector that causes the victim to open it with an FFmpeg-based application.
4. Trigger decoding: When the victim opens or plays the file, FFmpeg's RASC decoder automatically processes the stream, the mc pointer becomes dangling after reallocation, and the decoder reads 16 bytes from freed heap memory.
5. Achieve denial of service: On hardened builds (ASan, hardened allocator), this results in a deterministic crash; on standard glibc, behavior is heap-layout dependent (Red Hat Bugzilla).

• File System: Unexpected or unsolicited AVI files delivered via email, downloads, or shared storage, particularly those with unusual RIFF structure or very small RASC video dimensions.
• Process: FFmpeg or FFmpeg-based application processes (e.g., ffplay, ffmpeg, media players using libavcodec) crashing unexpectedly when opening AVI files; crash dumps referencing libavcodec/rasc.c or decode_move().
• Logs: Application crash logs or core dumps showing stack traces involving decode_move(), decode_zlib(), or av_fast_padded_malloc() in the RASC decoder context; ASan reports indicating heap-use-after-free in rasc.c (Red Hat Bugzilla).

The fix (PR #22992 by Michael Niedermayer) has been applied to FFmpeg master and introduces a dedicated scratch buffer (s->mv_scratch) for type-0 pixel copy operations, ensuring s->delta and mc are not disturbed during reallocation. Users should update to an FFmpeg build that includes this patch. As a workaround where patching is not immediately possible, disabling RASC decoder support at compile time (CONFIG_RASC_DECODER=no) or restricting processing of untrusted AVI files can mitigate the risk (Red Hat Bugzilla, FFmpeg Patchwork).