From: Cong Nguyen <congnt264@gmail.com>
To: 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: [PATCH v2] staging: greybus: light: fix leak of cdev->name
Date: Sun, 2 Aug 2026 13:01:49 +0700 [thread overview]
Message-ID: <20260802060149.3803224-1-congnt264@gmail.com> (raw)
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>
---
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
next reply other threads:[~2026-08-02 6:01 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-08-02 6:01 Cong Nguyen [this message]
2026-08-03 10:46 ` [PATCH v2] staging: greybus: light: fix leak of cdev->name Rui Miguel Silva
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=20260802060149.3803224-1-congnt264@gmail.com \
--to=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.