Re: [PATCH v2 58/61] drm/vmwgfx: Convert to atomic_create_state

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

Pre-existing issues:
- [High] Missing NULL check on `plane->state` leads to a NULL pointer dereference in `kmemdup()`.
--

--- Patch [58]: [PATCH v2 58/61] drm/vmwgfx: Convert to atomic_create_state ---
commit 4ecc3dc3826a2081d66677b1fc848a7ce4eeb905
Author: Maxime Ripard <[email protected]>

drm/vmwgfx: Convert to atomic_create_state

The plane reset implementation creates a custom state subclass, but only
initializes a pristine state without resetting any hardware. This is
equivalent to what atomic_create_state expects. Convert to it.

> diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c b/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c
> index 1b407b61f6838..dd9960060b08b 100644
> --- a/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c
> +++ b/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c
> @@ -287,27 +287,24 @@ vmw_du_plane_duplicate_state(struct drm_plane *plane)

[Severity: High]
This is a pre-existing issue, but I noticed a potential NULL pointer
dereference in vmw_du_plane_duplicate_state() which is located just above
this diff hunk.

If vmw_du_plane_create_state() fails to allocate memory, it returns
ERR_PTR(-ENOMEM). The DRM core handles this but can leave plane->state as
NULL. Later, when an atomic commit accesses the plane, it invokes
vmw_du_plane_duplicate_state(), which does:

	vps = kmemdup(plane->state, sizeof(*vps), GFP_KERNEL);

Since plane->state is passed directly to kmemdup() without a NULL check,
could this lead to a kernel panic during userspace atomic commits? The CRTC
and connector equivalents appear to have a WARN_ON(!crtc->state) guard.
Should a similar check be added for planes?

>  
>  
>  /**
> - * vmw_du_plane_reset - creates a blank vmw plane state
> + * vmw_du_plane_create_state - creates a blank vmw plane state

[ ... ]

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/[email protected]?part=58