PT-2026-86732 · Azure Linux · Kernel
Published
2026-08-28
·
Updated
2026-08-28
None
No severity ratings or metrics are available. When they are, we'll update the corresponding info on the page.
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.
Found an issue in the description? Have something to add? Feel free to write us 👾
Related Identifiers
Affected Products
Kernel