Bug 2529510 (CVE-2026-86476)

Summary: 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
Product: [Other] Security Response Reporter: OSIDB Bzimport <bzimport>
Component: vulnerabilityAssignee: Product Security <prodsec-ir-bot>
Status: NEW --- QA Contact:
Severity: high Docs Contact:
Priority: high    
Version: unspecifiedCC: gtanzill, jbuscemi, rhel-process-autobot, security-response-team, watson-tool-maintainers
Target Milestone: ---Keywords: Security
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: ---
Doc Text:
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.
 Story Points: ---
Clone Of: Environment:
Last Closed: Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On: 2552106, 2552107    
Bug Blocks:    

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