REDHAT-BUG-2529510: Buffer Overflow
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. gstvideoframemapid() (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 strideheight fits within the backing allocation. The no-meta branch (line 121) guards against this with 'if (frame->map[0].size < info->size) goto invalidsize', but the meta branch has no equivalent check.
2. defaultmap() (gstvideometa.c:398-432): Calls gstbufferfindmemory(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. videometadeserialize() (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. gstvideoframecopyplane() (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 1000000240 = 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 gstvideoframecopyplane() / videoorcconvertI420BGRA.
No upstream fix version or commit is known at time of writing. PSIRT Ticket: PSIRTSUPT-23320
Affected Software
Event History
Frequently Asked Questions
What conditions are required for exploitation?
An attacker must be able to supply an untrusted buffer carrying a GstVideoMeta to a code path that maps or copies video frames. The crafted metadata uses plane strides that extend beyond the buffer’s backing allocation.
Which deployments should be treated as potentially affected?
The issue is present in gst-plugins-base/libgstvideo version 1.29.2.1 on the development branch, and the available information states that earlier stable versions are also affected. Applications processing video buffers from untrusted peers should be prioritized for triage.