All of lore.kernel.org
 help / color / mirror / Atom feed
From: Rui Miguel Silva <rui.silva@linaro.org>
To: "Cong Nguyen" <congnt264@gmail.com>,
	"Rui Miguel Silva" <rmfrfs@gmail.com>,
	"Johan Hovold" <johan@kernel.org>,
	"Alex Elder" <elder@kernel.org>,
	"Greg Kroah-Hartman" <gregkh@linuxfoundation.org>
Cc: <greybus-dev@lists.linaro.org>, <linux-staging@lists.linux.dev>,
	<linux-kernel@vger.kernel.org>
Subject: Re: [PATCH v2] staging: greybus: light: fix leak of cdev->name
Date: Mon, 03 Aug 2026 11:46:51 +0100	[thread overview]
Message-ID: <DKF8YRNCVG1E.2F0JZKNLBEMHF@linaro.com> (raw)
In-Reply-To: <20260802060149.3803224-1-congnt264@gmail.com>

Hi Cong,
Thanks for the patch.

On Sun Aug 2, 2026 at 7:01 AM WEST, Cong Nguyen wrote:

> gb_lights_channel_config() builds the LED classdev name with kasprintf()
> and stores it in cdev->name for every channel during the configuration
> phase, which runs before the channel is registered.
>
> That name was only released by __gb_lights_led_unregister(), i.e. only for
> a normal LED channel that was actually registered. It was therefore leaked
> in two cases:
>
>   - a channel that is configured but never registered, e.g.
>     channel_attr_groups_set() fails, the flash configuration fails, or a
>     later channel in the same light fails to configure and the whole light
>     is torn down; the release path calls gb_lights_channel_unregister()
>     (which returns early because the channel is not registered) and then
>     gb_lights_channel_free();
>
>   - a flash, torch or indicator channel, whose unregister path
>     (__gb_lights_flash_led_unregister()) never releases cdev->name at all,
>     so the name leaks even on a successful teardown.
>
> cdev->name is a configuration-phase allocation, like channel->color_name
> and channel->mode_name. Free it in gb_lights_channel_free() next to
> those, since that runs unconditionally on every teardown path, and drop
> the special case free from __gb_lights_led_unregister().
> gb_lights_channel_unregister() is only ever called from
> gb_lights_channel_release(), immediately followed by
> gb_lights_channel_free(), so the name is still released on the registered
> path and is freed exactly once.
>
> Commit 04820da21050 ("staging: greybus: light: Release memory obtained by
> kasprintf") fixed the leak for the registered normal-LED path only; this
> covers the remaining cases.
>
> Fixes: 2870b52bae4c ("greybus: lights: add lights implementation")
> Assisted-by: Claude:claude-opus-4
> Signed-off-by: Cong Nguyen <congnt264@gmail.com>

Good Catch, LGTM.
Reviewed-by: Rui Miguel Silva <rui.silva@linaro.org>

Cheers,
    RUi
> ---
> Changes in v2:
> - Add Assisted-by: tag to document AI assistance, per
>   Documentation/process/coding-assistants.rst (Greg KH).
> - No functional change.
>
>  drivers/staging/greybus/light.c | 5 +++--
>  1 file changed, 3 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/staging/greybus/light.c b/drivers/staging/greybus/light.c
> index cab02b5da867..1ecca479b5f4 100644
> --- a/drivers/staging/greybus/light.c
> +++ b/drivers/staging/greybus/light.c
> @@ -905,8 +905,6 @@ static void __gb_lights_led_unregister(struct gb_channel *channel)
>  		return;
>  
>  	led_classdev_unregister(cdev);
> -	kfree(cdev->name);
> -	cdev->name = NULL;
>  	channel->led = NULL;
>  }
>  
> @@ -1063,6 +1061,9 @@ static int gb_lights_light_register(struct gb_light *light)
>  
>  static void gb_lights_channel_free(struct gb_channel *channel)
>  {
> +	struct led_classdev *cdev = get_channel_cdev(channel);
> +
> +	kfree(cdev->name);
>  	kfree(channel->attrs);
>  	kfree(channel->attr_group);
>  	kfree(channel->attr_groups);
> -- 
> 2.25.1




      reply	other threads:[~2026-08-03 10:46 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-08-02  6:01 [PATCH v2] staging: greybus: light: fix leak of cdev->name Cong Nguyen
2026-08-03 10:46 ` Rui Miguel Silva [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=DKF8YRNCVG1E.2F0JZKNLBEMHF@linaro.com \
    --to=rui.silva@linaro.org \
    --cc=congnt264@gmail.com \
    --cc=elder@kernel.org \
    --cc=gregkh@linuxfoundation.org \
    --cc=greybus-dev@lists.linaro.org \
    --cc=johan@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-staging@lists.linux.dev \
    --cc=rmfrfs@gmail.com \
    /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.