REDHAT-BUG-2541468: Medium severity GStreamer gst-plugins-bad vulnerability
GStreamer's asfmux plugin (gst-plugins-bad) contains a heap out-of-bounds write in the ASF header buffer allocation path. The functions contentdescriptioncalcsizefortag() (line 429) and addmetadatatagsize() (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 + gutf8strlen(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 gstasfmuxwritestringwithsize() (line 881) uses gconvert() which produces the correct (larger) UTF-16LE byte count. The header buffer is allocated at gstasfmuxstartfile() (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
Affected Software
Event History
Frequently Asked Questions
What input is needed to trigger the overflow?
The ASF muxer must process string metadata containing non-BMP Unicode characters, such as emoji or other code points at U+10000 and above. Each such character causes the header-size calculation to be 2 bytes too small.
Which deployments are exposed?
Deployments using the asfmux plugin from GStreamer gst-plugins-bad are affected when they mux ASF content with relevant string metadata. The issue is in the ASF header generation path, not merely in decoding or playback.
How can I identify potentially affected workflows?
Check whether gst-plugins-bad with the asfmux plugin is installed and whether your application supplies user-controlled or externally sourced metadata tags while producing ASF files. Metadata containing emoji or other non-BMP characters is the relevant indicator.
What can be done while a fix is unavailable?
Avoid passing non-BMP characters in string metadata processed by the ASF muxer. Restricting metadata to characters representable as a single UTF-16 code unit avoids the described size mismatch.