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
