CVE-2026-80701: drm/vmwgfx: enforce cursor size limits for MOB cursors
In the Linux kernel, the following vulnerability has been resolved:
drm/vmwgfx: enforce cursor size limits for MOB cursors
vmwcursorplaneatomiccheck() bounds cursor width and height only on the legacy update path; the SVGACAP2CURSORMOB path -- the default on modern hosts -- accepts any size. When the requested size exceeds SVGAREGCURSORMAXDIMENSION or SVGAREGMOBMAXSIZE, vmwcursormobget() returns -EINVAL and leaves vps->cursor.mob NULL. Its return value is then discarded in vmwcursorplanepreparefb(), so the subsequent vmwcursorupdatemob() calls vmwbomapandcache(NULL) and oopses inside vmwbomapandcachesize() on the tbo.base.size load.
Reachable from any DRM master via DRMIOCTLMODECURSOR2 with a sufficiently large width or height (e.g. cursormaxdim + 1).
Reject oversized cursors in atomiccheck for both MOB-backed cursor update types. The MOB byte-size limit only applies to the SVGACAP2CURSORMOB path (vmwcursormobsize() returns 0 for GBONLY); compute the required MOB size in 64-bit to avoid overflow when very large dimensions are requested.
In preparefb only call vmwcursormobget()/map() for VMWCURSORUPDATEMOB -- the GBONLY path uses bo->map.virtual directly and would otherwise be silently downgraded to NONE on hosts without SVGACAP2CURSORMOB (where vmwcursormobget() always returns -EINVAL). Degrade the update to NONE if vmwcursormobget() or vmwcursormobmap() fails so the update path does not run with a NULL backing MOB.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
ubuntu/linux-hwe-7.0to a version that resolves this vulnerability.Fixed in 7.0.0-42.42~24.04.1 - Upgrade
Upgrade
ubuntu/linux-riscv-7.0to a version that resolves this vulnerability.Fixed in 7.0.0-42.42.1~24.04.1 - Upgrade
Upgrade
ubuntu/linuxto a version that resolves this vulnerability.Fixed in 7.0.0-42.42 - Upgrade
Upgrade
ubuntu/linux-awsto a version that resolves this vulnerability.Fixed in 7.0.0-1016.17 - Upgrade
Upgrade
ubuntu/linux-gcpto a version that resolves this vulnerability.Fixed in 7.0.0-1016.18 - Upgrade
Upgrade
ubuntu/linux-ibmto a version that resolves this vulnerability.Fixed in 7.0.0-1017.17 - Upgrade
Upgrade
ubuntu/linux-oem-7.0to a version that resolves this vulnerability.Fixed in 7.0.0-1017.17 - Upgrade
Upgrade
ubuntu/linux-oracleto a version that resolves this vulnerability.Fixed in 7.0.0-1015.16 - Upgrade
Upgrade
ubuntu/linux-riscvto a version that resolves this vulnerability.Fixed in 7.0.0-42.42.1 - Compensating control
Reject oversized cursors in atomic_check for both MOB-backed cursor update types, enforcing SVGA_REG_CURSOR_MAX_DIMENSION and SVGA_REG_MOB_MAX_SIZE; compute the required MOB size in 64-bit to avoid overflow.
- Compensating control
Degrade the update to NONE if vmw_cursor_mob_get() or vmw_cursor_mob_map() fails, so the update path does not run with a NULL backing MOB.
- Compensating control
In vmw_cursor_plane_prepare_fb(), call vmw_cursor_mob_get() and vmw_cursor_mob_map() only for VMW_CURSOR_UPDATE_MOB; the GB_ONLY path must use bo->map.virtual directly.
Event History
Frequently Asked Questions
Who can trigger the crash?
Any DRM master can reach the vulnerable path through DRM_IOCTL_MODE_CURSOR2 by requesting a cursor with sufficiently large width or height. This is not limited to a particular application in the provided data.
Are modern default configurations affected?
Yes. The affected SVGA_CAP2_CURSOR_MOB cursor path is described as the default on modern hosts. The issue occurs when an oversized cursor causes MOB allocation to fail and the failure is ignored.
What input is needed to exploit the issue?
An attacker needs DRM-master access and must submit a cursor update whose width or height exceeds the relevant cursor or MOB size limit, such as cursor_max_dim + 1. The resulting NULL MOB pointer can cause a kernel oops during cursor update processing.
How is the issue fixed?
The fix rejects oversized cursor dimensions during atomic checking for both MOB-backed cursor update types. It also calculates required MOB size using 64-bit arithmetic and restricts MOB get/map operations to the MOB update path.