CVE-2026-80700

drm/vmwgfx: validate external BO copy bounds for both stride paths

HIGH
7.8
CVSS Score
Published: August 28, 2026 at 06:53 AM UTC
Updated: October 16, 2026 at 08:18 PM UTC
1 product affected across 1 vendorLinux Kernel

Using Linux by Linux?

Get instant alerts when new vulnerabilities affect Linux - before attackers find them.

Real-time alertsTrack your software stackFree plan available
Severity
HIGH7.8
Exploit prediction
EPSS 0.1%
SSVC
No known exploit

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.

Affected

Our own answer: ranges merged, affected separated from platform-only, with confidence and review flags.

50f1199250912568606b3778dc56646c10cb7b045c12391ee1ab59cb2f3be3f1f5e6d0fc0c2dc8546.10.86.116.6.499a9716bbbf3dd6b6cbefba3abcc89af8b72631f4
Vendor states this is fixed in 042ca38779554687fc32b66a28328e0d9a36c58f (fixed)
Vendor states this is fixed in 4e0f669e2951b742239c6fe847fcc406fe78748d (fixed)
Vendor states this is fixed in 5e4a2d15637a906cbd9bc98e0bf969f5f713e344 (fixed)
Vendor states this is fixed in 706c93c5813caabbb0d0a576c017d15aeec2c113 (fixed)
Vendor states this is fixed in e7b25a6011781ebfdbc458552cae6d4156732771 (fixed)
Vendor states this is fixed in 6.11 (unaffected)
Vendor states this is fixed in 6.12.103 (unaffected)
Vendor states this is fixed in 6.18.44 (unaffected)
Vendor states this is fixed in 6.6.151 (unaffected)
Vendor states this is fixed in 7.1.8 (unaffected)
Vendor states this is fixed in 7.2 (unaffected)

Remediation

No guide yet

No remediation guidance has been written for this CVE yet, and no fixed version or vendor advisory is recorded against it.

SSVC — Action Prioritization

SSVCNo known exploitNot automatableTotal impact

SSVC signals action urgency (what to patch first), separate from CVSS which measures severity.

CVSS

7.8HIGHLinux
Vector?

Quick Info

StatusRECEIVED

Get alerted

Stop reading CVE feeds looking for your own stack

Track the products you run and VulnTracker tells you when a new CVE affects them — with what is known about fixing it, and nothing about the rest.

Free plan, no card