Disclaimer: Community trackers are created by Red Hat Product Security team on a best effort basis. Package maintainers are required to ascertain if the flaw indeed affects their package, before starting the update process.

GStreamer's asfmux plugin (gst-plugins-bad) contains a heap out-of-bounds write in the ASF header buffer allocation path. The functions content_description_calc_size_for_tag() (line 429) and add_metadata_tag_size() (line 539) in subprojects/gst-plugins-bad/gst/asfmux/gstasfmux.c compute the UTF-16LE buffer size for string metadata tags using the formula `2 * (1 + g_utf8_strlen(text, -1))`. This counts Unicode code points and assumes each maps to one 16-bit UTF-16 code unit. However, non-BMP characters (U+10000 and above, e.g. emoji) require UTF-16 surrogate pairs (4 bytes per character). The write path in gst_asf_mux_write_string_with_size() (line 881) uses g_convert() which produces the correct (larger) UTF-16LE byte count. The header buffer is allocated at gst_asf_mux_start_file() (line 1332) using the pre-computed sizes. The resulting under-allocation is 2 bytes per non-BMP code point. The overflowing bytes are attacker-derived UTF-16LE content written via memcpy() at line 898.

The issue affects GStreamer versions containing the asfmux plugin in gst-plugins-bad. Reproduced at commit 4cb910d273bef5445c90e77e7b781ab99e236e1f (main branch). The affected size calculation is unchanged on current main.

Fix: Not yet available upstream (reported privately to GStreamer security team, awaiting triage).

Reporter: Bruno Fournier (xxtqqtx)
PSIRT Ticket: PSIRTSUPT-24645