CVE-2026-86476: Gstreamer1-plugins-base: gst-plugins-base: heap buffer overflow via unvalidated gstvideometa plane extents in gst_video_frame_map_id and video_meta_deserialize
A flaw was found in gst-plugins-base. A heap buffer overflow can be triggered when processing video buffers whose attached GstVideoMeta metadata declares plane strides and offsets that exceed the actual backing memory allocation. The metadata is not range-checked during deserialization, and the video frame mapping code does not verify that the declared plane geometry fits within the buffer before allowing consumers to read or write video data. A local attacker who controls the sending side of a GStreamer inter-process IPC pipeline can deliver a crafted buffer carrying fabricated strides, causing the receiving process to read or write beyond heap boundaries. Successful exploitation can cause a denial of service or potentially allow code execution within the affected process.
Other sources
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
— Red Hat