All of lore.kernel.org
 help / color / mirror / Atom feed
From: sashiko-bot@kernel.org
To: "Evgenii Burenchev" <evg28bur@yandex.ru>
Cc: dri-devel@lists.freedesktop.org
Subject: Re: [PATCH v2] drm/amd/display: Fix dangling pointers in state reset functions on allocation failure
Date: Fri, 26 Jun 2026 13:48:24 +0000	[thread overview]
Message-ID: <20260626134825.2F2131F000E9@smtp.kernel.org> (raw)
In-Reply-To: <20260626133859.21492-1-evg28bur@yandex.ru>

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] The old connector state memory is leaked during a successful connector reset in `amdgpu_dm_connector_funcs_reset()`.
--

commit 48ece48fead57764b257711d256ed0e86eefc3c4
Author: Evgenii Burenchev <evg28bur@yandex.ru>
Subject: drm/amd/display: Fix dangling pointers in state reset functions on allocation failure

This patch addresses dangling pointers in AMD display state reset functions by
allocating new state structures before destroying the old ones.

> diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> index eb5696b5daeb7..c7fe28758e962 100644
> --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> @@ -8151,33 +8151,35 @@ static void amdgpu_dm_connector_destroy(struct drm_connector *connector)
>  
>  void amdgpu_dm_connector_funcs_reset(struct drm_connector *connector)
>  {
> -	struct dm_connector_state *state =
> -		to_dm_connector_state(connector->state);
> -
> -	if (connector->state)
> -		__drm_atomic_helper_connector_destroy_state(connector->state);
> -
> -	kfree(state);
> +	struct dm_connector_state *state;
>  
> +	/* Allocate new state first */
>  	state = kzalloc_obj(*state);
> +	if (WARN_ON(!state))
> +		return;
>  
> -	if (state) {
> -		state->scaling = RMX_OFF;

[ ... ]

> +	/* Destroy old state only after successful allocation */
> +	if (connector->state)
> +		__drm_atomic_helper_connector_destroy_state(connector->state);
>  
> -		__drm_atomic_helper_connector_reset(connector, &state->base);
> +	/* Let DRM core install the new state */
> +	__drm_atomic_helper_connector_reset(connector, &state->base);

[Severity: Medium]
Does this code leak the old connector state memory?

The original code explicitly called kfree(state) after calling
__drm_atomic_helper_connector_destroy_state(connector->state). The new
implementation removes this kfree() call.

Looking at __drm_atomic_helper_connector_destroy_state(), it only cleans up
references to nested DRM objects (like CRTCs or properties) but does not free
the connector_state structure itself. When __drm_atomic_helper_connector_reset()
then overwrites connector->state with the new pointer, it appears to
permanently orphan the old memory.

Should the old state memory be explicitly freed here as it was previously?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260626133859.21492-1-evg28bur@yandex.ru?part=1

  reply	other threads:[~2026-06-26 13:48 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-06-26 13:38 [PATCH v2] drm/amd/display: Fix dangling pointers in state reset functions on allocation failure Evgenii Burenchev
2026-06-26 13:48 ` sashiko-bot [this message]
2026-06-26 17:24 ` Mario Limonciello

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=20260626134825.2F2131F000E9@smtp.kernel.org \
    --to=sashiko-bot@kernel.org \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=evg28bur@yandex.ru \
    --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.