Bug 2529510 (CVE-2026-86476) - 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
Summary: CVE-2026-86476 gstreamer1-plugins-base: gst-plugins-base: heap buffer overflo...
Keywords:
Status: NEW
Alias: CVE-2026-86476
Product: Security Response
Classification: Other
Component: vulnerability
Version: unspecified
Hardware: All
OS: Linux
high
high
Target Milestone: ---
Assignee: Product Security
QA Contact:
URL:
Whiteboard:
Depends On: 2552106 2552107
Blocks:
TreeView+ depends on / blocked
 
Reported: 2026-09-07 15:28 UTC by OSIDB Bzimport
Modified: 2026-10-14 08:03 UTC (History)
5 users (show)

Fixed In Version:
Clone Of:
Environment:
Last Closed:
Embargoed:


Attachments (Terms of Use)

Description OSIDB Bzimport 2026-09-07 15:28:08 UTC
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.

No upstream fix version or commit is known at time of writing.
PSIRT Ticket: PSIRTSUPT-23320


Note You need to log in before you can comment on or make changes to this bug.