CVE-2026-80700 in Linux
Summary
by MITRE • 08/28/2026
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.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Analysis
by VulDB Data Team • 08/28/2026
The vulnerability identified in the Linux kernel's VMware graphics driver (vmwgfx) represents a critical memory safety flaw within the buffer object copy functionality, specifically affecting how external buffer objects are handled during display updates. The core issue resides in the vmw_external_bo_copy function, which is responsible for copying data between imported dma-buf virtual mappings used by the Direct Rendering Manager subsystem. This function processes two distinct code paths based on whether source and destination strides match: a bulk memcpy path for equal strides and a row-by-row copy path for unequal strides. In both scenarios, the implementation fails to adequately validate user-supplied parameters such as offsets, strides, and heights before performing memory operations. Because these values are derived from STDU (Source Transfer Unit) or SOU plane state submitted via atomic commits on imported framebuffers, an attacker with access to display configuration capabilities can craft malicious inputs that trigger out-of-bounds memory accesses.
In the equal-stride path, the vulnerability manifests through integer arithmetic errors leading to buffer overflows. The code attempts to clamp memcpy bounds by subtracting offsets from destination and source sizes. However, if a supplied offset exceeds the size of the buffer object, unsigned subtraction results in wraparound, producing an extremely large positive value instead of a negative error indicator. This oversized value is then passed to memcpy, causing it to read or write far beyond the allocated virtual memory mapping. Additionally, the calculation involving dst_stride multiplied by height utilizes 32-bit integer multiplication which lacks overflow protection. If these values are sufficiently large, they wrap around to small numbers, potentially bypassing subsequent checks and allowing writes that exceed buffer boundaries. This specific flaw aligns with CWE-190 (Integer Overflow or Wraparound) as the root cause of the memory corruption.
The non-equal-stride path presents an even more severe risk due to a complete absence of bound validation for row-by-row copying operations. The loop iterates through rows using offsets and strides without verifying that the final byte accessed remains within the allocated buffer limits. The only existing check, WARN_ON(dst_stride < width_in_bytes), serves merely as a debugging aid rather than a security control and does not prevent out-of-bounds access when stride is greater than or equal to width but still allows traversal past the end of the mapping. Consequently, an attacker can manipulate these parameters to cause reads from arbitrary kernel memory locations or writes that corrupt adjacent data structures in kernel space. This behavior corresponds directly to CWE-787 (Out-of-bounds Write) and CWE-125 (Out-of-bounds Read), representing a fundamental failure in input validation for buffer boundaries.
The operational impact of this vulnerability is significant, as it allows for potential privilege escalation or system instability within the Linux kernel environment. Since the flaw can be triggered through atomic commits on imported framebuffers, an unprivileged user with access to graphical interfaces or virtualization consoles may exploit this condition. Successful exploitation could lead to arbitrary code execution by overwriting critical kernel data structures such as function pointers or control flow metadata. Alternatively, it might result in a denial of service through kernel panics caused by accessing unmapped memory pages. The vulnerability is particularly dangerous because imported framebuffers often involve complex interactions between user-space applications and the graphics driver, providing multiple attack vectors for local privilege escalation attacks against systems running VMware virtualization environments or similar configurations utilizing vmwgfx drivers.
To mitigate this risk, developers have implemented rigorous validation checks using check_mul_overflow() and check_add_overflow() functions to detect integer arithmetic errors before they result in invalid memory addresses. These safeguards ensure that calculations involving strides, heights, and offsets do not wrap around or exceed safe limits. Furthermore, the logic has been refined to reject zero strides and cases where stride is less than width_in_bytes, conditions under which the row-by-row copy path cannot safely operate without risking out-of-bounds access. The bulk memcpy optimization is now restricted to scenarios where width_in_bytes fully covers the stride, ensuring that partial-row updates near framebuffer boundaries are handled correctly by copying one row at a time when necessary. These changes enforce strict boundary checks consistent with secure coding practices and align with ATT&CK technique T1059 (Command and Scripting Interpreter) if exploited for initial access or lateral movement within compromised systems, although the primary classification remains related to memory corruption vulnerabilities like those tracked under CWE-787 and CWE-125.