CVE-2026-80701 in Linux
Summary
by MITRE • 08/28/2026
In the Linux kernel, the following vulnerability has been resolved:
drm/vmwgfx: enforce cursor size limits for MOB cursors
vmw_cursor_plane_atomic_check() bounds cursor width and height only on the legacy update path; the SVGA_CAP2_CURSOR_MOB path -- the default on modern hosts -- accepts any size. When the requested size exceeds SVGA_REG_CURSOR_MAX_DIMENSION or SVGA_REG_MOB_MAX_SIZE, vmw_cursor_mob_get() returns -EINVAL and leaves vps->cursor.mob NULL. Its return value is then discarded in vmw_cursor_plane_prepare_fb(), so the subsequent vmw_cursor_update_mob() calls vmw_bo_map_and_cache(NULL) and oopses inside vmw_bo_map_and_cache_size() on the tbo.base.size load.
Reachable from any DRM master via DRM_IOCTL_MODE_CURSOR2 with a sufficiently large width or height (e.g. cursor_max_dim + 1).
Reject oversized cursors in atomic_check for both MOB-backed cursor update types. The MOB byte-size limit only applies to the SVGA_CAP2_CURSOR_MOB path (vmw_cursor_mob_size() returns 0 for GB_ONLY); compute the required MOB size in 64-bit to avoid overflow when very large dimensions are requested.
In prepare_fb only call vmw_cursor_mob_get()/_map() for VMW_CURSOR_UPDATE_MOB -- the GB_ONLY path uses bo->map.virtual directly and would otherwise be silently downgraded to NONE on hosts without SVGA_CAP2_CURSOR_MOB (where vmw_cursor_mob_get() always returns -EINVAL). 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.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.
Analysis
by VulDB Data Team • 08/28/2026
The vulnerability in question resides within the VMware SVGA graphics driver for the Linux kernel, specifically affecting the cursor plane atomic check and preparation logic. This flaw allows an attacker to trigger a null pointer dereference leading to a system crash or denial of service by exploiting insufficient input validation regarding cursor dimensions. The issue is particularly critical because it affects modern hosts that utilize the SVGA_CAP2_CURSOR_MOB path for handling mouse cursors, which has become the default configuration in many environments. Unlike legacy update paths where width and height bounds were strictly enforced, this specific code path failed to validate these parameters before proceeding with memory operations, creating a significant security gap accessible through standard display management interfaces.
The technical root cause lies in how vmw_cursor_plane_atomic_check handles cursor size validation. While the function correctly restricts dimensions for legacy updates, it neglects to apply similar bounds checking when SVGA_CAP2_CURSOR_MOB is active. Consequently, if an application requests a cursor with width or height exceeding SVGA_REG_CURSOR_MAX_DIMENSION or causing the calculated MOB byte-size to exceed SVGA_REG_MOB_MAX_SIZE, the subsequent call to vmw_cursor_mob_get returns -EINVAL and leaves vps->cursor.mob as NULL. Crucially, in vmw_cursor_plane_prepare_fb, this error return value is discarded rather than handled appropriately. This oversight means that control flow continues under the assumption that a valid memory-backed object exists for the cursor data.
When execution proceeds to vmw_cursor_update_mob with a null pointer representing the MOB backing store, the driver attempts to map and cache this non-existent buffer by calling vmw_bo_map_and_cache(NULL). Inside vmw_bo_map_and_cache_size, the code attempts to access tbo.base.size on a NULL structure reference. This operation triggers an immediate kernel panic or oops due to null pointer dereference. The vulnerability is reachable from any DRM master process via the DRM_IOCTL_MODE_CURSOR2 ioctl interface by supplying sufficiently large width and height values that exceed internal limits but are not caught during initial validation phases.
From a security classification perspective, this flaw aligns with CWE-476 NULL Pointer Dereference, as it involves accessing memory through an uninitialized or null pointer due to improper error handling. It also relates to CWE-20 Improper Input Validation because the system fails to adequately sanitize user-supplied dimensions before processing them into kernel structures. In terms of attack vectors, this vulnerability can be exploited locally by any unprivileged user who has access to a DRM device node, fitting within MITRE ATT&CK techniques related to Denial of Service via local exploitation or resource exhaustion through malformed input parameters sent to graphics subsystems.
The operational impact of this vulnerability is primarily a denial of service against the host system running the affected Linux kernel version. An attacker can crash the entire operating environment by repeatedly sending oversized cursor update requests, effectively rendering the graphical interface and potentially other dependent services unavailable until a reboot occurs. There are no indications that this flaw allows for arbitrary code execution or privilege escalation directly; however, the stability of the system is severely compromised. In virtualized environments where multiple guests might interact with shared graphics resources, such instability could disrupt broader infrastructure operations depending on deployment configurations.
Mitigation strategies involve applying vendor-provided kernel patches that enforce strict cursor size limits across all update paths, including those utilizing MOB-backed cursors. Developers have addressed this by ensuring vmw_cursor_plane_atomic_check validates dimensions for both legacy and modern SVGA_CAP2_CURSOR_MOB paths. Additionally, the fix includes computing required MOB sizes using 64-bit arithmetic to prevent integer overflows when handling very large dimension requests. Error handling in vmw_cursor_plane_prepare_fb has been improved so that failures from vmw_cursor_mob_get or map operations result in downgrading the update type rather than proceeding with null pointers. System administrators should ensure their kernels are updated to versions containing these fixes and monitor for any signs of graphical subsystem instability indicative of attempted exploitation attempts.