Answer in brief
CVE-2026-80700 records a High severity (CVSS 7.8) vulnerability in drm/vmwgfx: validate external BO copy bounds for both stride paths. The current sources do not mark it as known exploited. The current feed maps Linux/Linux (generic), Linux/Linux (generic). Check affected ranges and fixed versions before updating.
Analysis pending evidence review
HOL Guard separates source facts from reviewed analysis. See the methodology.
CVSS is 7.8. The current sources do not mark it as known exploited. Treat this as a source-backed prioritization signal, not a statement about your environment.
Analysis status
Analysis pending evidence review
Factual feed record only; HOL analysis is not approved for indexing. Read the methodology.
The current feed maps Linux/Linux (generic), Linux/Linux (generic). Check affected ranges and fixed versions before updating.
| Package | Affected range | Fixed version |
|---|---|---|
| Linux/Linuxgeneric | >=9a9716bbbf3dd6b6cbefba3abcc89af8b72631f4 <4e0f669e2951b742239c6fe847fcc406fe78748d || >=50f1199250912568606b3778dc56646c10cb7b04 <e7b25a6011781ebfdbc458552cae6d4156732771 || >=50f1199250912568606b3778dc56646c10cb7b04 <042ca38779554687fc32b66a28328e0d9a36c58f || >=50f1199250912568606b3778dc56646c10cb7b04 <5e4a2d15637a906cbd9bc98e0bf969f5f713e344 || >=50f1199250912568606b3778dc56646c10cb7b04 <706c93c5813caabbb0d0a576c017d15aeec2c113 || 5c12391ee1ab59cb2f3be3f1f5e6d0fc0c2dc854 || >=6.6.49 <6.6.151 || >=6.10.8 <6.11 | 4e0f669e2951b742239c6fe847fcc406fe78748d, e7b25a6011781ebfdbc458552cae6d4156732771, 042ca38779554687fc32b66a28328e0d9a36c58f, 5e4a2d15637a906cbd9bc98e0bf969f5f713e344, 706c93c5813caabbb0d0a576c017d15aeec2c113, 6.6.151, 6.11 |
| Linux/Linuxgeneric | 6.11 | Not reported |
Published upstream
Aug 28, 2026
Evidence: source:cvelist:source_dates:source-dates:recordSource modified
Aug 29, 2026
Evidence: source:cvelist:source_dates:source-dates:recordFirst seen by HOL
Aug 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.
Quoted source text, attributed separately from HOL analysis.