[PATCH] drm/vmwgfx: Treat zero SVGA_REG_CURSOR_MAX_DIMENSION as unset

[PATCH] drm/vmwgfx: Treat zero SVGA_REG_CURSOR_MAX_DIMENSION as unset

[fausten]

The cursor plane code validates cursor dimensions against
SVGA_REG_CURSOR_MAX_DIMENSION before every cursor update, and
rejects the update with -EINVAL if the cursor is larger than the
reported maximum.

However, some SVGA implementations do not implement this register
and return 0 for it. In that case every cursor update is rejected,
and the log is spammed with:

  [drm] Cursor dimensions (64, 64) exceed device max 0

The visible symptom is that the hardware cursor never appears at
all on VMware Fusion guests (SVGA version 2), making the mouse
pointer invisible even though the input devices work fine.

Treat a reported maximum of 0 as "not implemented" and skip the
dimension check in that case, restoring the pre-existing behaviour
of accepting the cursor.

Tested on VMware Fusion with an SVGA version 2 device where the
cursor previously did not show up.

Fixes: d5ed8749168a ("drm/vmwgfx: enforce cursor size limits for MOB cursors")
Signed-off-by: fausten <yunfeng.li.nb@email.com>
---
 drivers/gpu/drm/vmwgfx/vmwgfx_cursor_plane.c | 12 ++++++++----
 1 file changed, 8 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_cursor_plane.c b/drivers/gpu/drm/vmwgfx/vmwgfx_cursor_plane.c
index d1e7df500..fbdd23ecb 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_cursor_plane.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_cursor_plane.c
@@ -237,8 +237,10 @@ static int vmw_cursor_mob_get(struct vmw_cursor_plane *vcp,
 	mob_max_size = vmw_read(dev_priv, SVGA_REG_MOB_MAX_SIZE);
 	cursor_max_dim = vmw_read(dev_priv, SVGA_REG_CURSOR_MAX_DIMENSION);
 
-	if (size > mob_max_size || vps->base.crtc_w > cursor_max_dim ||
-	    vps->base.crtc_h > cursor_max_dim)
+	/* Some SVGA implementations (e.g. VMware Fusion) report 0 here. */
+	if (cursor_max_dim &&
+	    (size > mob_max_size || vps->base.crtc_w > cursor_max_dim ||
+	     vps->base.crtc_h > cursor_max_dim))
 		return -EINVAL;
 
 	if (vps->cursor.mob) {
@@ -748,8 +750,10 @@ int vmw_cursor_plane_atomic_check(struct drm_plane *plane,
 		u32 cursor_max_dim =
 			vmw_read(vmw, SVGA_REG_CURSOR_MAX_DIMENSION);
 
-		if (new_state->crtc_w > cursor_max_dim ||
-		    new_state->crtc_h > cursor_max_dim) {
+		/* Some SVGA implementations (e.g. VMware Fusion) report 0 here. */
+		if (cursor_max_dim &&
+		    (new_state->crtc_w > cursor_max_dim ||
+		    new_state->crtc_h > cursor_max_dim)) {
 			drm_warn(&vmw->drm,
 				 "Cursor dimensions (%d, %d) exceed device max %u\n",
 				 new_state->crtc_w, new_state->crtc_h,
-- 
2.33.0

[PATCH v2] drm/vmwgfx: Treat zero SVGA_REG_CURSOR_MAX_DIMENSION as unset

[fausten]

The cursor plane code validates cursor dimensions against
SVGA_REG_CURSOR_MAX_DIMENSION before every cursor update, and
rejects the update with -EINVAL if the cursor is larger than the
reported maximum.

However, some SVGA implementations do not implement this register
and return 0 for it. In that case every cursor update is rejected,
and the log is spammed with:

  [drm] Cursor dimensions (64, 64) exceed device max 0

The visible symptom is that the hardware cursor never appears at
all on VMware Fusion guests (SVGA version 2), making the mouse
pointer invisible even though the input devices work fine.

Treat a reported maximum of 0 as "not implemented" and skip the
dimension check in that case, restoring the pre-existing behaviour
of accepting the cursor.

Tested on VMware Fusion with an SVGA version 2 device where the
cursor previously did not show up.

Fixes: d5ed8749168a ("drm/vmwgfx: enforce cursor size limits for MOB cursors")
Signed-off-by: fausten <yunfeng.li.nb@gmail.com>
---
Changes in v2:
- Fix author name and email address (v1 was sent with a wrong From).

 drivers/gpu/drm/vmwgfx/vmwgfx_cursor_plane.c | 12 ++++++++----
 1 file changed, 8 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_cursor_plane.c b/drivers/gpu/drm/vmwgfx/vmwgfx_cursor_plane.c
index d1e7df500..fbdd23ecb 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_cursor_plane.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_cursor_plane.c
@@ -237,8 +237,10 @@ static int vmw_cursor_mob_get(struct vmw_cursor_plane *vcp,
 	mob_max_size = vmw_read(dev_priv, SVGA_REG_MOB_MAX_SIZE);
 	cursor_max_dim = vmw_read(dev_priv, SVGA_REG_CURSOR_MAX_DIMENSION);
 
-	if (size > mob_max_size || vps->base.crtc_w > cursor_max_dim ||
-	    vps->base.crtc_h > cursor_max_dim)
+	/* Some SVGA implementations (e.g. VMware Fusion) report 0 here. */
+	if (cursor_max_dim &&
+	    (size > mob_max_size || vps->base.crtc_w > cursor_max_dim ||
+	     vps->base.crtc_h > cursor_max_dim))
 		return -EINVAL;
 
 	if (vps->cursor.mob) {
@@ -748,8 +750,10 @@ int vmw_cursor_plane_atomic_check(struct drm_plane *plane,
 		u32 cursor_max_dim =
 			vmw_read(vmw, SVGA_REG_CURSOR_MAX_DIMENSION);
 
-		if (new_state->crtc_w > cursor_max_dim ||
-		    new_state->crtc_h > cursor_max_dim) {
+		/* Some SVGA implementations (e.g. VMware Fusion) report 0 here. */
+		if (cursor_max_dim &&
+		    (new_state->crtc_w > cursor_max_dim ||
+		    new_state->crtc_h > cursor_max_dim)) {
 			drm_warn(&vmw->drm,
 				 "Cursor dimensions (%d, %d) exceed device max %u\n",
 				 new_state->crtc_w, new_state->crtc_h,
-- 
2.33.0

Re: [PATCH v2] drm/vmwgfx: Treat zero SVGA_REG_CURSOR_MAX_DIMENSION as unset

[sashiko-bot]

Thank you for your contribution! Sashiko AI review found 3 potential issue(s) to consider:

Pre-existing issues:
- [Critical] Integer overflows in framebuffer creation and cursor command submission cause a Guest-to-Host Out-Of-Bounds Read.
- [High] Missing Error Handling / NULL Pointer Dereference in `vmw_cursor_plane_prepare_fb`.
- [High] State Confusion in `vmw_cursor_plane_atomic_check` allows bypassing legacy cursor dimension checks, leading to a massive kernel heap Out-Of-Bounds read.
--

--- Patch [1]: [PATCH v2] drm/vmwgfx: Treat zero SVGA_REG_CURSOR_MAX_DIMENSION as unset ---
commit fc08a38eba647596145d861cab4214687c5ce5ce
Author: fausten <yunfeng.li.nb@gmail.com>

drm/vmwgfx: Treat zero SVGA_REG_CURSOR_MAX_DIMENSION as unset

This commit treats a reported SVGA_REG_CURSOR_MAX_DIMENSION of 0 as "not
implemented" and skips the cursor dimension check in that case. This restores
the pre-existing behaviour for VMware Fusion guests (SVGA version 2) where the
cursor previously did not show up.

> diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_cursor_plane.c b/drivers/gpu/drm/vmwgfx/vmwgfx_cursor_plane.c
> index d1e7df5001903..fbdd23ecb2b4b 100644
> --- a/drivers/gpu/drm/vmwgfx/vmwgfx_cursor_plane.c
> +++ b/drivers/gpu/drm/vmwgfx/vmwgfx_cursor_plane.c
[ ... ]
> @@ -748,8 +750,10 @@ int vmw_cursor_plane_atomic_check(struct drm_plane *plane,
>  		u32 cursor_max_dim =
>  			vmw_read(vmw, SVGA_REG_CURSOR_MAX_DIMENSION);
>  
> -		if (new_state->crtc_w > cursor_max_dim ||
> -		    new_state->crtc_h > cursor_max_dim) {
> +		/* Some SVGA implementations (e.g. VMware Fusion) report 0 here. */
> +		if (cursor_max_dim &&
> +		    (new_state->crtc_w > cursor_max_dim ||
> +		    new_state->crtc_h > cursor_max_dim)) {

[Severity: High]
This isn't a bug introduced by this patch, but does the cursor plane code handle
BO mapping failures safely?

In drivers/gpu/drm/vmwgfx/vmwgfx_cursor_plane.c:vmw_cursor_plane_prepare_fb(),
the return value of vmw_bo_map_and_cache_size() is cast to void, ignoring
potential mapping failures:

    (void)vmw_bo_map_and_cache_size(bo, size);

If this mapping fails, bo->map.virtual remains NULL. Later, in
vmw_cursor_plane_atomic_update(), vmw_send_define_cursor_cmd() unconditionally
copies to the command buffer using the unvalidated image pointer:

    memcpy(&cmd[1], image, image_size);

Could this cause a NULL pointer dereference and kernel panic if memory
pressure causes the mapping to fail?

[Severity: High]
This is a pre-existing issue, but does skipping this dimension check expose
a state confusion bug that could lead to an out-of-bounds read?

In drivers/gpu/drm/vmwgfx/vmwgfx_cursor_plane.c:vmw_cursor_plane_atomic_check(),
update_type is evaluated using vmw_cursor_update_type(vmw, vps). At this point,
vps->uo contains stale state from the previous commit, as it isn't updated until
vmw_cursor_plane_prepare_fb().

If userspace commits a BO-backed cursor (GB_ONLY), and then in a subsequent
commit submits a Surface-backed cursor (LEGACY) with huge dimensions
(e.g., 512x512), atomic_check will evaluate the type as GB_ONLY.

Since this patch skips the dimension check when cursor_max_dim == 0,
the huge dimensions are accepted. When prepare_fb() runs, vps->uo is updated
and the type correctly becomes LEGACY.

Finally, in vmw_send_define_cursor_cmd(), the memcpy() reads width * height * 4
bytes from the 16KB legacy surface->snooper.image buffer:

    memcpy(&cmd[1], image, image_size);

Could this result in a massive out-of-bounds read of the kernel heap being
sent to the hypervisor?

[Severity: Critical]
This is a pre-existing issue, but does bypassing this check when
cursor_max_dim == 0 expose integer overflows that can cause a guest-to-host
out-of-bounds read?

If userspace creates a framebuffer with massive dimensions (e.g., 32768x32768),
the calculation in drivers/gpu/drm/vmwgfx/vmwgfx_kms.c:vmw_kms_new_framebuffer_bo()
overflows 32 bits:

    requested_size = mode_cmd->height * mode_cmd->pitches[0];
    if (unlikely(requested_size > bo->tbo.base.size)) {

This overflow to 0 allows creating a massive framebuffer with a 1-page BO.
Because this patch removes the dimension limit for cursor_max_dim == 0,
the large cursor dimensions are accepted.

When vmw_send_define_cursor_cmd() prepares the command:

    const u32 image_size = width * height * sizeof(*image);
    const u32 cmd_size = sizeof(*cmd) + image_size;

image_size overflows to 0, resulting in only sizeof(*cmd) bytes being allocated
in the command FIFO. The hypervisor receives the command specifying a
32768x32768 cursor but no pixel data follows in the FIFO.

Will this cause the hypervisor to read 4GB out-of-bounds from the command FIFO?

>  			drm_warn(&vmw->drm,
>  				 "Cursor dimensions (%d, %d) exceed device max %u\n",
>  				 new_state->crtc_w, new_state->crtc_h,

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260823085916.2707488-1-yunfeng.li.nb@gmail.com?part=1

Re: [PATCH v2] drm/vmwgfx: Treat zero SVGA_REG_CURSOR_MAX_DIMENSION as unset

[Maaz Mombasawala]

On 8/23/26 1:59 AM, fausten wrote:
> The cursor plane code validates cursor dimensions against
> SVGA_REG_CURSOR_MAX_DIMENSION before every cursor update, and
> rejects the update with -EINVAL if the cursor is larger than the
> reported maximum.
> 
> However, some SVGA implementations do not implement this register
> and return 0 for it. In that case every cursor update is rejected,
> and the log is spammed with:
> 
>   [drm] Cursor dimensions (64, 64) exceed device max 0
> 
> The visible symptom is that the hardware cursor never appears at
> all on VMware Fusion guests (SVGA version 2), making the mouse
> pointer invisible even though the input devices work fine.
> 
> Treat a reported maximum of 0 as "not implemented" and skip the
> dimension check in that case, restoring the pre-existing behaviour
> of accepting the cursor.
> 
> Tested on VMware Fusion with an SVGA version 2 device where the
> cursor previously did not show up.

I take it this is an x86_64 mac? What version of fusion are you using?
Also what is the hwVersion of your VM?

> 
> Fixes: d5ed8749168a ("drm/vmwgfx: enforce cursor size limits for MOB cursors")
> Signed-off-by: fausten <yunfeng.li.nb@gmail.com>
> ---
> Changes in v2:
> - Fix author name and email address (v1 was sent with a wrong From).
> 
>  drivers/gpu/drm/vmwgfx/vmwgfx_cursor_plane.c | 12 ++++++++----
>  1 file changed, 8 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_cursor_plane.c b/drivers/gpu/drm/vmwgfx/vmwgfx_cursor_plane.c
> index d1e7df500..fbdd23ecb 100644
> --- a/drivers/gpu/drm/vmwgfx/vmwgfx_cursor_plane.c
> +++ b/drivers/gpu/drm/vmwgfx/vmwgfx_cursor_plane.c
> @@ -237,8 +237,10 @@ static int vmw_cursor_mob_get(struct vmw_cursor_plane *vcp,
>  	mob_max_size = vmw_read(dev_priv, SVGA_REG_MOB_MAX_SIZE);
>  	cursor_max_dim = vmw_read(dev_priv, SVGA_REG_CURSOR_MAX_DIMENSION);
>  
> -	if (size > mob_max_size || vps->base.crtc_w > cursor_max_dim ||
> -	    vps->base.crtc_h > cursor_max_dim)
> +	/* Some SVGA implementations (e.g. VMware Fusion) report 0 here. */
> +	if (cursor_max_dim &&
> +	    (size > mob_max_size || vps->base.crtc_w > cursor_max_dim ||
> +	     vps->base.crtc_h > cursor_max_dim))
>  		return -EINVAL;
>  
>  	if (vps->cursor.mob) {
> @@ -748,8 +750,10 @@ int vmw_cursor_plane_atomic_check(struct drm_plane *plane,
>  		u32 cursor_max_dim =
>  			vmw_read(vmw, SVGA_REG_CURSOR_MAX_DIMENSION);
>  
> -		if (new_state->crtc_w > cursor_max_dim ||
> -		    new_state->crtc_h > cursor_max_dim) {
> +		/* Some SVGA implementations (e.g. VMware Fusion) report 0 here. */
> +		if (cursor_max_dim &&
> +		    (new_state->crtc_w > cursor_max_dim ||
> +		    new_state->crtc_h > cursor_max_dim)) {
>  			drm_warn(&vmw->drm,
>  				 "Cursor dimensions (%d, %d) exceed device max %u\n",
>  				 new_state->crtc_w, new_state->crtc_h,


-- 
Maaz Mombasawala <maaz.mombasawala@broadcom.com>

Re: [PATCH v2] drm/vmwgfx: Treat zero SVGA_REG_CURSOR_MAX_DIMENSION as unset

[Maaz Mombasawala]

On 8/23/26 1:59 AM, fausten wrote:
> The cursor plane code validates cursor dimensions against
> SVGA_REG_CURSOR_MAX_DIMENSION before every cursor update, and
> rejects the update with -EINVAL if the cursor is larger than the
> reported maximum.
> 
> However, some SVGA implementations do not implement this register
> and return 0 for it. In that case every cursor update is rejected,
> and the log is spammed with:
> 
>   [drm] Cursor dimensions (64, 64) exceed device max 0
> 
> The visible symptom is that the hardware cursor never appears at
> all on VMware Fusion guests (SVGA version 2), making the mouse
> pointer invisible even though the input devices work fine.
> 
> Treat a reported maximum of 0 as "not implemented" and skip the
> dimension check in that case, restoring the pre-existing behaviour
> of accepting the cursor.
> 
> Tested on VMware Fusion with an SVGA version 2 device where the
> cursor previously did not show up.
> 
> Fixes: d5ed8749168a ("drm/vmwgfx: enforce cursor size limits for MOB cursors")
> Signed-off-by: fausten <yunfeng.li.nb@gmail.com>
> ---
> Changes in v2:
> - Fix author name and email address (v1 was sent with a wrong From).
> 
>  drivers/gpu/drm/vmwgfx/vmwgfx_cursor_plane.c | 12 ++++++++----
>  1 file changed, 8 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_cursor_plane.c b/drivers/gpu/drm/vmwgfx/vmwgfx_cursor_plane.c
> index d1e7df500..fbdd23ecb 100644
> --- a/drivers/gpu/drm/vmwgfx/vmwgfx_cursor_plane.c
> +++ b/drivers/gpu/drm/vmwgfx/vmwgfx_cursor_plane.c
> @@ -237,8 +237,10 @@ static int vmw_cursor_mob_get(struct vmw_cursor_plane *vcp,
>  	mob_max_size = vmw_read(dev_priv, SVGA_REG_MOB_MAX_SIZE);
>  	cursor_max_dim = vmw_read(dev_priv, SVGA_REG_CURSOR_MAX_DIMENSION);
>  
> -	if (size > mob_max_size || vps->base.crtc_w > cursor_max_dim ||
> -	    vps->base.crtc_h > cursor_max_dim)
> +	/* Some SVGA implementations (e.g. VMware Fusion) report 0 here. */

The issue here is not with vmware fusion but the hw version, SVGA_REG_CURSOR_MAX_DIMENSION requires cursor mobs,
which are available only on hw versions 18 and above. Please correct the comment here and below to reflect that.

> +	if (cursor_max_dim &&

Could you instead do cursor_max_dim > 0 here and below.

> +	    (size > mob_max_size || vps->base.crtc_w > cursor_max_dim ||
> +	     vps->base.crtc_h > cursor_max_dim))
>  		return -EINVAL;
>  
>  	if (vps->cursor.mob) {
> @@ -748,8 +750,10 @@ int vmw_cursor_plane_atomic_check(struct drm_plane *plane,
>  		u32 cursor_max_dim =
>  			vmw_read(vmw, SVGA_REG_CURSOR_MAX_DIMENSION);
>  
> -		if (new_state->crtc_w > cursor_max_dim ||
> -		    new_state->crtc_h > cursor_max_dim) {
> +		/* Some SVGA implementations (e.g. VMware Fusion) report 0 here. */
> +		if (cursor_max_dim &&
> +		    (new_state->crtc_w > cursor_max_dim ||
> +		    new_state->crtc_h > cursor_max_dim)) {
>  			drm_warn(&vmw->drm,
>  				 "Cursor dimensions (%d, %d) exceed device max %u\n",
>  				 new_state->crtc_w, new_state->crtc_h,


-- 
Maaz Mombasawala <maaz.mombasawala@broadcom.com>

Re: [PATCH v3] drm/vmwgfx: Treat zero SVGA_REG_CURSOR_MAX_DIMENSION as unset

[sashiko-bot]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] Bypassing the `cursor_max_dim` check for older hardware removes all size limits for `VMW_CURSOR_UPDATE_GB_ONLY` cursors, leading to kernel deadlocks.
--

commit 40fdf3cf95cd9e88874c6ede6ef6e1bfc8402258
Author: Yunfeng Li <yunfeng.li.nb@gmail.com>

drm/vmwgfx: Treat zero SVGA_REG_CURSOR_MAX_DIMENSION as unset

This commit modifies the cursor plane validation to skip the maximum dimension
check if the hardware reports a maximum of 0 (like SVGA version 2). This
fixes an issue on VMware Fusion guests where the hardware cursor would fail
to appear due to the register not being implemented.

> diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_cursor_plane.c b/drivers/gpu/drm/vmwgfx/vmwgfx_cursor_plane.c
> --- a/drivers/gpu/drm/vmwgfx/vmwgfx_cursor_plane.c
> +++ b/drivers/gpu/drm/vmwgfx/vmwgfx_cursor_plane.c

[ ... ]

> @@ -748,8 +750,10 @@ int vmw_cursor_plane_atomic_check(struct drm_plane *plane,
>  		u32 cursor_max_dim =
>  			vmw_read(vmw, SVGA_REG_CURSOR_MAX_DIMENSION);
>  
> -		if (new_state->crtc_w > cursor_max_dim ||
> -		    new_state->crtc_h > cursor_max_dim) {
> +		/* Cursor MOBs, and thus this register, exist only on hw version 18+. */
> +		if (cursor_max_dim > 0 &&
> +		    (new_state->crtc_w > cursor_max_dim ||
> +		     new_state->crtc_h > cursor_max_dim)) {

[Severity: High]
Does skipping this dimension check when cursor_max_dim is 0 allow userspace
to request arbitrarily large cursors?

If a user requests a massive cursor (e.g., 4096x4096), this check is bypassed
and the update proceeds. Later, vmw_send_define_cursor_cmd() attempts to
allocate a command buffer for the cursor:

drivers/gpu/drm/vmwgfx/vmwgfx_cursor_plane.c:vmw_send_define_cursor_cmd() {
    ...
    const u32 image_size = width * height * sizeof(*image);
    const u32 cmd_size = sizeof(*cmd) + image_size;

    cmd = VMW_CMD_RESERVE(dev_priv, cmd_size);
    ...
}

For a 4096x4096 cursor, this results in a ~64MB allocation request. Since
this requested size vastly exceeds the typical command buffer pool, does
this cause the internal allocator to stall indefinitely?

drivers/gpu/drm/vmwgfx/vmwgfx_cmdbuf.c:vmw_cmdbuf_alloc_space() {
    ...
    } else {
        wait_event(man->alloc_queue, vmw_cmdbuf_try_alloc(man, &info));
    }
    ...
}

Because the space can never become available for such a large allocation,
it appears this creates an uninterruptible deadlock in the DRM KMS subsystem.

>  			drm_warn(&vmw->drm,
>  				 "Cursor dimensions (%d, %d) exceed device max %u\n",
>  				 new_state->crtc_w, new_state->crtc_h,

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260828110437.1592832-1-yunfeng.li.nb@gmail.com?part=1