CVE-2026-80700

medium Red Hat
CVSS v3 Base Score
7.0
CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H
EPSS Score
0.1%
Exploitation probability in 30 days
Top 97% most likely to be exploited
Attack Characteristics
Attack Vector
Local
Attack Complexity
High
Privileges Required
Low
User Interaction
None
Confidentiality
High
Integrity
High
Availability
High
Published: August 28, 2026 (9 days ago)
Last Modified: August 28, 2026
Vendor: Red Hat
Source: REDHAT

Description

In the Linux kernel, the following vulnerability has been resolved: drm/vmwgfx: validate external BO copy bounds for both stride paths vmw_external_bo_copy() trusts caller-supplied offsets, strides, and heights and operates on imported dma-buf vmaps: - The equal-stride memcpy() bound was clamped after subtracting the offsets from dst_size and src_size; an offset larger than the BO size wraps the unsigned subtraction to a huge value and the resulting memcpy() runs off the end of the vmap. dst_stride * height is also a u32 multiplication that can overflow. - The non-equal-stride row-by-row path had no bound at all. The loop touches bytes through offset + (height - 1) * stride + width_in_bytes, with only a WARN_ON(dst_stride < width_in_bytes), and could likewise step past the end of either mapping. The offsets and strides are derived from STDU/SOU plane state, so a configured CRTC submitting a crafted atomic commit on an imported framebuffer can reach this path. Validate the exact row-copy endpoint against each BO's size up front using check_mul_overflow() and check_add_overflow(). Use the bulk memcpy() path only when width_in_bytes covers the whole stride; otherwise copy one row at a time so partial-row updates near the bottom of a framebuffer remain valid. Also reject zero strides and stride < width_in_bytes, both of which the row-by-row path cannot represent safely.

CWE

CWE-787

Affected Products

Red Hat Enterprise Linux 10Red Hat Enterprise Linux 6Red Hat Enterprise Linux 7Red Hat Enterprise Linux 8Red Hat Enterprise Linux 9

References