CVE-2024-47834

What it actually does

Use-after-free read in gst_matroska_demux_parse_stream when handling CodecPrivate elements: memory is allocated via gst_ebml_read_binary, freed via g_free in gst_matroska_track_free, then read again in gst_value_serialize_buffer.

Why it matters to the business

Media playback or processing applications may crash or leak memory when handling untrusted Matroska files, potentially disrupting video workflows or exposing limited internal data.

How an attack unfolds

An attacker supplies a specially crafted Matroska file containing a CodecPrivate element that triggers the allocation-free-read sequence inside the GStreamer demuxer; when the file is opened by any application using the vulnerable library the freed buffer is accessed, resulting in a read of invalid memory.

How to fix it

Upgrade GStreamer to version 1.24.10 or later; apply commit 5be4b6f03689ab438822f6cfcd13f1f300afe203 in source builds.

How to confirm the fix worked

Confirm installed GStreamer version is 1.24.10 or newer; attempt playback of a test Matroska file containing CodecPrivate elements and verify absence of crashes or sanitizer reports.

Typical attack path

1. Create malicious Matroska container with crafted CodecPrivate data
2. Deliver file to target application that uses GStreamer
3. Trigger gst_matroska_demux_parse_stream during stream parsing
4. Reach caps_serialize after track memory has been freed

How to detect it

Review application logs and crash reports for GStreamer processes handling Matroska streams; correlate with file-open events involving .mkv or .webm containers from untrusted sources.

What your security team should do

• Update all GStreamer installations to 1.24.10 or newer
• Identify and replace any downstream applications still using vulnerable builds
• Temporarily disable Matroska demuxing for untrusted input until patches are deployed