All of 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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.