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
prev parent 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