[PATCH] leds: flash: sgm3140: fix child node reference leak

[PATCH] leds: flash: sgm3140: fix child node reference leak

[Guangshuo Li]

sgm3140_probe() obtains a reference to the LED child node with
device_get_next_child_node(). The probe error path correctly drops this
reference with fwnode_handle_put(), but the successful probe path
returns without releasing it.

v4l2_flash_init() takes its own reference to the supplied fwnode and
v4l2_flash_release() drops that reference during device removal.
Therefore, the reference acquired by sgm3140_probe() is only needed
during probe and can be released once initialization has completed.

Drop the child node reference before returning successfully from probe.

This issue was found by manual code inspection.

Fixes: cef8ec8cbd21 ("leds: add sgm3140 driver")
Cc: stable@vger.kernel.org
Signed-off-by: Guangshuo Li <lgs201920130244@gmail.com>
---
 drivers/leds/flash/leds-sgm3140.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/leds/flash/leds-sgm3140.c b/drivers/leds/flash/leds-sgm3140.c
index dc6840357370..51e31fdb78e5 100644
--- a/drivers/leds/flash/leds-sgm3140.c
+++ b/drivers/leds/flash/leds-sgm3140.c
@@ -273,7 +273,9 @@ static int sgm3140_probe(struct platform_device *pdev)
 		goto err;
 	}
 
-	return ret;
+	fwnode_handle_put(child_node);
+
+	return 0;
 
 err:
 	fwnode_handle_put(child_node);
-- 
2.43.0

Re: [PATCH] leds: flash: sgm3140: fix child node reference leak

[Laurent Pinchart]

On Mon, Sep 14, 2026 at 09:57:23PM +0800, Guangshuo Li wrote:
> sgm3140_probe() obtains a reference to the LED child node with
> device_get_next_child_node(). The probe error path correctly drops this
> reference with fwnode_handle_put(), but the successful probe path
> returns without releasing it.
> 
> v4l2_flash_init() takes its own reference to the supplied fwnode and
> v4l2_flash_release() drops that reference during device removal.

How about devm_led_classdev_flash_register_ext() ?

> Therefore, the reference acquired by sgm3140_probe() is only needed
> during probe and can be released once initialization has completed.
> 
> Drop the child node reference before returning successfully from probe.
> 
> This issue was found by manual code inspection.

I wonder what prompted you to manual inspect that code.

> Fixes: cef8ec8cbd21 ("leds: add sgm3140 driver")
> Cc: stable@vger.kernel.org
> Signed-off-by: Guangshuo Li <lgs201920130244@gmail.com>
> ---
>  drivers/leds/flash/leds-sgm3140.c | 4 +++-
>  1 file changed, 3 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/leds/flash/leds-sgm3140.c b/drivers/leds/flash/leds-sgm3140.c
> index dc6840357370..51e31fdb78e5 100644
> --- a/drivers/leds/flash/leds-sgm3140.c
> +++ b/drivers/leds/flash/leds-sgm3140.c
> @@ -273,7 +273,9 @@ static int sgm3140_probe(struct platform_device *pdev)
>  		goto err;
>  	}
>  
> -	return ret;
> +	fwnode_handle_put(child_node);
> +
> +	return 0;
>  
>  err:
>  	fwnode_handle_put(child_node);

-- 
Regards,

Laurent Pinchart

Re: [PATCH] leds: flash: sgm3140: fix child node reference leak

[sashiko-bot]

Thank you for your contribution! Sashiko AI review found 4 potential issue(s) to consider:

New issues:
- [Low] Non-capitalized description in commit message.

Pre-existing issues:
- [High] Use-After-Free of driver private data (priv) due to missing or incorrectly ordered del_timer_sync() for powerdown_timer.
- [High] The powerdown timer callback calls regulator_disable(), which can sleep, from atomic context.
- [High] Unbalanced regulator_disable() in timer handler due to missing timer cancellation in brightness_set(LED_OFF).
--

commit ee14e99da842d6c5f84775b78b062eac6483dedf
Author: Guangshuo Li <lgs201920130244@gmail.com>

leds: flash: sgm3140: fix child node reference leak

This commit fixes a missing fwnode_handle_put() call in the successful
probe path to avoid leaking a reference to the LED child node.

> leds: flash: sgm3140: fix child node reference leak

[Severity: Low]
This isn't a bug introduced by this patch, but the subsystem guidelines
mandate capitalizing the description after the subsystem prefix. Could
"fix" be capitalized to "Fix"?

> diff --git a/drivers/leds/flash/leds-sgm3140.c b/drivers/leds/flash/leds-sgm3140.c
> index d3a30ad94ac46..ab649e2c8f20a 100644
> --- a/drivers/leds/flash/leds-sgm3140.c
> +++ b/drivers/leds/flash/leds-sgm3140.c

[ ... ]

>  	/* Create V4L2 Flash subdev */
>  	priv->v4l2_flash = v4l2_flash_init(&pdev->dev,
>  					   child_node,
>  					   fled_cdev, NULL,
>  					   &v4l2_sd_cfg);
>  	if (IS_ERR(priv->v4l2_flash)) {
>  		ret = PTR_ERR(priv->v4l2_flash);
>  		goto err;
>  	}

[Severity: High]
This is a pre-existing issue, but I noticed the error path unwinds devm
allocations without canceling the powerdown timer. 

Since devm_led_classdev_flash_register_ext() is called before this step, 
userspace could theoretically trigger a flash strobe and arm the timer. If 
v4l2_flash_init() fails and we take this error path, devres callbacks will 
free the driver data. Could the timer expire later and access freed memory?

Also, looking at sgm3140_remove(), del_timer_sync() is called manually
before the devm-managed LED is unregistered. Could this create a race
window where the timer is re-armed before the driver fully unloads?

>  
> -	return ret;
> +	fwnode_handle_put(child_node);
> +
> +	return 0;
>  
>  err:
>  	fwnode_handle_put(child_node);

While reviewing the timer code, I also noticed a couple of other
pre-existing issues in the driver:

[Severity: High]
This is a pre-existing issue, but sgm3140_powerdown_timer() executes in
atomic context and calls regulator_disable(), which can sleep:

sgm3140_powerdown_timer()
   ...
   regulator_disable(priv->vin_regulator);

Can this lead to a scheduling while atomic panic when the timer expires?

[Severity: High]
This is a pre-existing issue, but sgm3140_brightness_set() disables the 
regulator when setting LED_OFF without canceling the powerdown timer:

sgm3140_brightness_set()
   ...
   } else {
       gpiod_set_value_cansleep(priv->enable_gpio, 0);
       ret = regulator_disable(priv->vin_regulator);

If the timer was armed by a previous strobe, it will expire later and 
unconditionally call regulator_disable() again:

sgm3140_powerdown_timer()
   ...
   regulator_disable(priv->vin_regulator);
   
Could this unbalanced regulator disable cause regulator core warnings or
unintended shutdown of shared regulators?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260914135723.1741327-1-lgs201920130244@gmail.com?part=1

Re: [PATCH] leds: flash: sgm3140: fix child node reference leak

[Guangshuo Li]

Hi Laurent,

Thanks for the review.

On Mon, 14 Sept 2026 at 22:17, Laurent Pinchart
<laurent.pinchart@ideasonboard.com> wrote:
>
> On Mon, Sep 14, 2026 at 09:57:23PM +0800, Guangshuo Li wrote:
> > sgm3140_probe() obtains a reference to the LED child node with
> > device_get_next_child_node(). The probe error path correctly drops this
> > reference with fwnode_handle_put(), but the successful probe path
> > returns without releasing it.
> >
> > v4l2_flash_init() takes its own reference to the supplied fwnode and
> > v4l2_flash_release() drops that reference during device removal.
>
> How about devm_led_classdev_flash_register_ext() ?
>
> > Therefore, the reference acquired by sgm3140_probe() is only needed
> > during probe and can be released once initialization has completed.
> >
> > Drop the child node reference before returning successfully from probe.
> >
> > This issue was found by manual code inspection.
>
> I wonder what prompted you to manual inspect that code.
>
> > Fixes: cef8ec8cbd21 ("leds: add sgm3140 driver")
> > Cc: stable@vger.kernel.org
> > Signed-off-by: Guangshuo Li <lgs201920130244@gmail.com>
> > ---
> >  drivers/leds/flash/leds-sgm3140.c | 4 +++-
> >  1 file changed, 3 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/leds/flash/leds-sgm3140.c b/drivers/leds/flash/leds-sgm3140.c
> > index dc6840357370..51e31fdb78e5 100644
> > --- a/drivers/leds/flash/leds-sgm3140.c
> > +++ b/drivers/leds/flash/leds-sgm3140.c
> > @@ -273,7 +273,9 @@ static int sgm3140_probe(struct platform_device *pdev)
> >               goto err;
> >       }
> >
> > -     return ret;
> > +     fwnode_handle_put(child_node);
> > +
> > +     return 0;
> >
> >  err:
> >       fwnode_handle_put(child_node);
>
> --
> Regards,
>
> Laurent Pinchart

The issue I was trying to fix is that the reference obtained by
device_get_next_child_node() is not released on the successful probe
path.

I missed that devm_led_classdev_flash_register_ext() stores the fwnode
in the LED class device without taking a reference of its own. Therefore,
dropping the reference at the end of probe, as in this patch, would be
too early.

I think the reference should instead be kept until the LED class device
is unregistered. I'll rework the fix to manage it with a devm action
registered before the LED class device registration and send a v2.

Thanks,
Guangshuo

Re: [PATCH] leds: flash: sgm3140: fix child node reference leak

[Laurent Pinchart]

On Mon, Sep 21, 2026 at 04:57:30PM +0800, Guangshuo Li wrote:
> On Mon, 14 Sept 2026 at 22:17, Laurent Pinchart wrote:
> > On Mon, Sep 14, 2026 at 09:57:23PM +0800, Guangshuo Li wrote:
> > > sgm3140_probe() obtains a reference to the LED child node with
> > > device_get_next_child_node(). The probe error path correctly drops this
> > > reference with fwnode_handle_put(), but the successful probe path
> > > returns without releasing it.
> > >
> > > v4l2_flash_init() takes its own reference to the supplied fwnode and
> > > v4l2_flash_release() drops that reference during device removal.
> >
> > How about devm_led_classdev_flash_register_ext() ?
> >
> > > Therefore, the reference acquired by sgm3140_probe() is only needed
> > > during probe and can be released once initialization has completed.
> > >
> > > Drop the child node reference before returning successfully from probe.
> > >
> > > This issue was found by manual code inspection.
> >
> > I wonder what prompted you to manual inspect that code.
> >
> > > Fixes: cef8ec8cbd21 ("leds: add sgm3140 driver")
> > > Cc: stable@vger.kernel.org
> > > Signed-off-by: Guangshuo Li <lgs201920130244@gmail.com>
> > > ---
> > >  drivers/leds/flash/leds-sgm3140.c | 4 +++-
> > >  1 file changed, 3 insertions(+), 1 deletion(-)
> > >
> > > diff --git a/drivers/leds/flash/leds-sgm3140.c b/drivers/leds/flash/leds-sgm3140.c
> > > index dc6840357370..51e31fdb78e5 100644
> > > --- a/drivers/leds/flash/leds-sgm3140.c
> > > +++ b/drivers/leds/flash/leds-sgm3140.c
> > > @@ -273,7 +273,9 @@ static int sgm3140_probe(struct platform_device *pdev)
> > >               goto err;
> > >       }
> > >
> > > -     return ret;
> > > +     fwnode_handle_put(child_node);
> > > +
> > > +     return 0;
> > >
> > >  err:
> > >       fwnode_handle_put(child_node);
> 
> The issue I was trying to fix is that the reference obtained by
> device_get_next_child_node() is not released on the successful probe
> path.
> 
> I missed that devm_led_classdev_flash_register_ext() stores the fwnode
> in the LED class device without taking a reference of its own. Therefore,
> dropping the reference at the end of probe, as in this patch, would be
> too early.
> 
> I think the reference should instead be kept until the LED class device
> is unregistered. I'll rework the fix to manage it with a devm action
> registered before the LED class device registration and send a v2.

Handling this in individual drivers with a devm action seems wrong.
Please understand what you're doing and fix things correctly.

-- 
Regards,

Laurent Pinchart