Bug 2490710 (CVE-2026-12706)
| Summary: | CVE-2026-12706 ffmpeg: ffmpeg: heap use-after-free read in RASC decoder decode_move() | ||
|---|---|---|---|
| Product: | [Other] Security Response | Reporter: | OSIDB Bzimport <bzimport> |
| Component: | vulnerability | Assignee: | Product Security <prodsec-ir-bot> |
| Status: | NEW --- | QA Contact: | |
| Severity: | medium | Docs Contact: | |
| Priority: | medium | ||
| Version: | unspecified | CC: | bbrownin, jkoehler, lphiri, rhel-process-autobot, watson-tool-maintainers |
| Target Milestone: | --- | Keywords: | Security |
| Target Release: | --- | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | --- | |
| Doc Text: |
A use-after-free vulnerability was found in FFmpeg's RASC video decoder. The decode_move() function initializes a read pointer into a decompressed buffer, but a subsequent reallocation of that same buffer during move-table processing leaves the pointer dangling. An attacker could exploit this by providing a specially crafted AVI file containing a malicious RASC video stream. When a user opens or plays the file, the decoder reads from freed heap memory, which could lead to a denial of service (crash).
|
Story Points: | --- |
| Clone Of: | Environment: | ||
| Last Closed: | Type: | --- | |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
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