Bug 2552106

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.

gst-plugins-base (libgstvideo) version 1.29.2.1 (development branch; earlier stable versions also affected) contains a heap buffer overflow in the video frame mapping and copy path. Two related root causes combine to allow an untrusted peer to deliver a GstVideoMeta with fabricated plane strides that extend far beyond the backing buffer allocation.

1. gst_video_frame_map_id() (video-frame.c:89-107): When a GstVideoMeta is present on a buffer, the meta branch copies width, height, offset, and stride from the meta into the GstVideoFrame without checking that stride*height fits within the backing allocation. The no-meta branch (line 121) guards against this with 'if (frame->map[0].size < info->size) goto invalid_size', but the meta branch has no equivalent check.

2. default_map() (gstvideometa.c:398-432): Calls gst_buffer_find_memory(buffer, offset, 1, ...) -- the '1' means only a single byte at the plane's start offset is verified to exist. The code contains the comment '/* FIXME use plane size */' confirming the known limitation. The meta's stride is then blindly written to *stride (line 416) and used by all consumers.

3. video_meta_deserialize() (gstvideometa.c:252-313): Deserializes GstVideoMeta from the unixfd IPC byte stream. Strides are read as signed gint32 (line 285), accepting negative values. No range check compares declared strides/offsets against the actual backing buffer size. The metadata is attached to an empty buffer before the peer-controlled memory is mapped, so the stride and the allocation are never compared.

4. gst_video_frame_copy_plane() (video-frame.c:391-400) and videoconvert ORC kernels: Both consume the frame's stride unconditionally. When strides are 1000000 on a 320x240 I420 buffer (actual allocation ~115200 bytes), a single plane memcpy attempts 1000000*240 = 240,000,000 bytes -- a massive OOB.

Upstream GitLab issue 5257 is confidential. Reporter: Yehia Ezzat (yehiaezzat710). ASan confirmed: heap-buffer-overflow READ of size 2073600 and WRITE of size 2073600, both faulting inside gst_video_frame_copy_plane() / video_orc_convert_I420_BGRA.

Upstream coordination (2026-09-07, Sebastian Dröge): CVSS 8.4 vector confirmed. No upstream fix commit yet. Upstream expects to land a fix during the week of 2026-09-07, targeting inclusion in GStreamer 1.28.8 (approximately one month; GStreamer 1.28.7 release imminent). Coordinated public disclosure date to be confirmed by upstream. Practical cross-process exposure is limited: disabling the unixfd plugin is the only known mitigation for that path, and upstream states the plugin is not used by software packaged in RHEL or major Linux distributions. The affected unixfdsink/unixfdsrc elements are not used automatically. The underlying libgstvideo validation gap may still affect in-process use if attacker-controlled GstVideoMeta is supplied by other code using metadata serialization (no known open source consumers per upstream).
PSIRT Ticket: PSIRTSUPT-23320