dri-devel Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: sashiko-bot@kernel.org
To: "Maxime Ripard" <mripard@kernel.org>
Cc: dri-devel@lists.freedesktop.org
Subject: Re: [PATCH v5 14/14] drm/vkms: Add driver-specific plane property for testing
Date: Fri, 16 Oct 2026 07:49:10 +0000	[thread overview]
Message-ID: <sashiko-outbox-173967@kernel.org> (raw)
In-Reply-To: <20261016-drm-reset-state-flag-v5-14-dad2d64b693b@kernel.org>

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] vkms: NULL pointer dereference in vkms_plane_create_state on property alloc failure
--

commit d0a4c2c6cd5d0119f8db12db7c2a842adce4aa8a
Author: Maxime Ripard <mripard@kernel.org>

drm/vkms: Add driver-specific plane property for testing

This commit adds a driver-specific range property to vkms planes for testing
the DRM_MODE_ATOMIC_RESET flag. It initializes the property during plane
creation and duplicates its value in the plane state.

> diff --git a/drivers/gpu/drm/vkms/vkms_plane.c b/drivers/gpu/drm/vkms/vkms_plane.c
> index fd3d34dcf0fe5..0ebc131c2788f 100644
> --- a/drivers/gpu/drm/vkms/vkms_plane.c
> +++ b/drivers/gpu/drm/vkms/vkms_plane.c
[ ... ]
> @@ -85,7 +92,9 @@ static void vkms_plane_destroy_state(struct drm_plane *plane,
>  
>  static struct drm_plane_state *vkms_plane_create_state(struct drm_plane *plane)
>  {
> +	struct vkms_plane *vkms_plane = to_vkms_plane(plane);
>  	struct vkms_plane_state *vkms_state;
> +	u64 val;
>  
>  	vkms_state = kzalloc_obj(*vkms_state);
>  	if (!vkms_state) {
> @@ -95,14 +104,53 @@ static struct drm_plane_state *vkms_plane_create_state(struct drm_plane *plane)
>  
>  	__drm_gem_shadow_plane_state_init(plane, &vkms_state->base);
>  
> +	if (!drm_object_property_get_default_value(&plane->base,
> +						   vkms_plane->vkms_test_do_not_use_property,
> +						   &val))

[Severity: High]
Can vkms_plane->vkms_test_do_not_use_property be NULL here?

In vkms_plane_init(), if drm_property_create_range() fails, the property
pointer is left as NULL, but initialization succeeds:

	plane->vkms_test_do_not_use_property =
		drm_property_create_range(dev, 0,
					  "vkms-test-do-not-use-in-prod",
					  0, U32_MAX);
	if (plane->vkms_test_do_not_use_property)
		drm_object_attach_property(&plane->base.base,
					   plane->vkms_test_do_not_use_property,
					   0);

If the property pointer is NULL, calling
drm_object_property_get_default_value() will trigger a NULL pointer
dereference because the DRM core unconditionally dereferences it:

drivers/gpu/drm/drm_mode_object.c:drm_object_property_get_default_value() {
	WARN_ON(!drm_drv_uses_atomic_modeset(property->dev));
    ...
}

Should there be a NULL check for vkms_test_do_not_use_property before passing
it to drm_object_property_get_default_value(), or should vkms_plane_init()
return an error if the property allocation fails?

> +		vkms_state->vkms_test_do_not_use_value = val;
> +
>  	return &(&vkms_state->base)->base;
>  }

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20261016-drm-reset-state-flag-v5-0-dad2d64b693b@kernel.org?part=14

      reply	other threads:[~2026-10-16  7:49 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-10-16  7:31 [PATCH v5 00/14] drm: Add DRM_MODE_ATOMIC_RESET flag Maxime Ripard
2026-10-16  7:31 ` [PATCH v5 01/14] drm/atomic: Switch to krealloc_array() in drm_atomic_get_private_obj_state() Maxime Ripard
2026-10-16  7:31 ` [PATCH v5 02/14] drm/atomic: Use __GFP_ZERO instead of explicit memset " Maxime Ripard
2026-10-16  7:31 ` [PATCH v5 03/14] drm/atomic: Use __GFP_ZERO instead of explicit memset in drm_atomic_get_connector_state() Maxime Ripard
2026-10-16  7:31 ` [PATCH v5 04/14] drm/atomic: Create function to insert CRTC state into a commit Maxime Ripard
2026-10-16  7:31 ` [PATCH v5 05/14] drm/atomic: Create function to insert plane " Maxime Ripard
2026-10-16  7:31 ` [PATCH v5 06/14] drm/atomic: Create function to insert colorop " Maxime Ripard
2026-10-16  7:31 ` [PATCH v5 07/14] drm/atomic: Create function to insert private obj " Maxime Ripard
2026-10-16  7:31 ` [PATCH v5 08/14] drm/atomic: Create function to insert connector " Maxime Ripard
2026-10-16  7:31 ` [PATCH v5 09/14] drm/atomic: Add drm_atomic_implements_create_state() helper Maxime Ripard
2026-10-16  7:31 ` [PATCH v5 10/14] drm/atomic: Allow filling a commit with pristine object states Maxime Ripard
2026-10-16  7:31 ` [PATCH v5 11/14] drm/tests: atomic: Add tests for drm_atomic_commit_fill_with_defaults() Maxime Ripard
2026-10-16  7:52   ` sashiko-bot
2026-10-16  7:31 ` [PATCH v5 12/14] drm/atomic-uapi: Add DRM_MODE_ATOMIC_RESET flag Maxime Ripard
2026-10-16  7:54   ` sashiko-bot
2026-10-16  7:31 ` [PATCH v5 13/14] drm/vkms: Switch container_of helpers to container_of_const Maxime Ripard
2026-10-16  7:31 ` [PATCH v5 14/14] drm/vkms: Add driver-specific plane property for testing Maxime Ripard
2026-10-16  7:49   ` sashiko-bot [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=sashiko-outbox-173967@kernel.org \
    --to=sashiko-bot@kernel.org \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=mripard@kernel.org \
    --cc=sashiko-reviews@lists.linux.dev \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox