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.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "7.8",
  "pubDate": "2026-08-28T08:16:55.517Z",
  "pubdate": "2026-08-28T08:16:55.517Z",
  "executiveSummary": "The Linux kernel vmwgfx driver contains a critical vulnerability in the vmw_external_bo_copy() function involving insufficient input validation for imported dma-buf buffer objects.\nThis vulnerability is classified as an out-of-bounds (OOB) memory access, potentially leading to kernel memory corruption, privilege escalation, or system instability.\nThe flaw affects systems using the VMware guest graphics driver (vmwgfx).\nAttackers with the capability to trigger atomic commits on an imported framebuffer can manipulate stride, offset, and height parameters to bypass internal bounds checks.\nSuccessful exploitation requires the ability to interact with the DRM subsystem, typically requiring local access, though the impact is severe due to the potential for kernel-level code execution or data leakage.\nThe vulnerability highlights a failure to safely calculate memory offsets in both equal-stride and row-by-row memory copy paths, allowing attackers to read from or write to arbitrary kernel memory.",
  "technicalDetails": "The root cause of the vulnerability lies in the improper handling of user-supplied buffer dimensions within the vmw_external_bo_copy() function. The function trusts caller-provided offsets, strides, and heights when operating on dma-buf vmaps, leading to two distinct failure modes.\nIn the equal-stride memcpy() path, the driver calculates bounds by subtracting user-supplied offsets from buffer sizes. If an attacker provides an offset larger than the actual buffer object (BO) size, the unsigned subtraction wraps around to a massive integer value. This bypassed check causes the subsequent memcpy() to perform an out-of-bounds write or read. Furthermore, the calculation 'dst_stride * height' is susceptible to a u32 integer overflow, which can be leveraged to pass size checks while remaining fundamentally unsafe for the underlying buffer allocation.\nIn the non-equal-stride path (row-by-row copy), the driver previously lacked any effective bound checking. The loop logic attempted to access bytes based on 'offset + (height - 1) * stride + width_in_bytes'. The original implementation relied on a weak WARN_ON(dst_stride < width_in_bytes) check, which failed to prevent memory access beyond the destination or source mapping boundaries. Because these parameters are derived from STDU/SOU (Surface Transfer Display Unit/Screen Object Unit) plane state, a malicious actor can craft an atomic commit specifically designed to trigger these unsafe calculations.\nThe attack flow begins with the malicious user-space application importing a dma-buf and configuring a CRTC with crafted plane state parameters. By providing specific, invalid stride and offset combinations, the attacker forces the vmwgfx driver to execute memory copies that exceed the allocated physical memory of the buffer objects. This results in the kernel writing or reading outside the intended buffer memory area.\nThis behavior can lead to the corruption of sensitive kernel structures located adjacent to the buffer in memory, facilitating local privilege escalation. Because this logic executes within the kernel context, an attacker might be able to overwrite function pointers or other critical data to redirect control flow. The vulnerability is fundamentally a failure of the driver to perform rigorous mathematical validation using primitives like check_mul_overflow() and check_add_overflow() prior to performing memory copies."
}