From: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
To: Cong Nguyen <congnt264@gmail.com>
Cc: Rui Miguel Silva <rmfrfs@gmail.com>,
Johan Hovold <johan@kernel.org>, Alex Elder <elder@kernel.org>,
greybus-dev@lists.linaro.org, linux-staging@lists.linux.dev,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH] staging: greybus: light: fix leak of cdev->name
Date: Tue, 28 Jul 2026 09:17:11 +0200 [thread overview]
Message-ID: <2026072842-protract-matcher-99b6@gregkh> (raw)
In-Reply-To: <20260726110039.3674948-1-congnt264@gmail.com>
On Sun, Jul 26, 2026 at 06:00:39PM +0700, 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")
> Signed-off-by: Cong Nguyen <congnt264@gmail.com>
> ---
> drivers/staging/greybus/light.c | 5 +++--
> 1 file changed, 3 insertions(+), 2 deletions(-)
>
Cool, but how did you find this issue? What tool did you use?
thanks,
greg k-h
prev parent reply other threads:[~2026-07-28 7:17 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-07-26 11:00 [PATCH] staging: greybus: light: fix leak of cdev->name Cong Nguyen
2026-07-28 7:17 ` Greg Kroah-Hartman [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=2026072842-protract-matcher-99b6@gregkh \
--to=gregkh@linuxfoundation.org \
--cc=congnt264@gmail.com \
--cc=elder@kernel.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.