lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20250811165358.79b3128c@akair>
Date: Mon, 11 Aug 2025 16:53:58 +0200
From: Andreas Kemnade <andreas@...nade.info>
To: Miaoqian Lin <linmq006@...il.com>
Cc: Aaro Koskinen <aaro.koskinen@....fi>, Kevin Hilman
 <khilman@...libre.com>, Roger Quadros <rogerq@...nel.org>, Tony Lindgren
 <tony@...mide.com>, linux-omap@...r.kernel.org,
 linux-kernel@...r.kernel.org, linux-clk@...r.kernel.org
Subject: Re: [PATCH] bus: ti-sysc: Fix potential double free in
 sysc_add_named_clock_from_child()

Hi,

Am Mon,  4 Aug 2025 20:04:03 +0800
schrieb Miaoqian Lin <linmq006@...il.com>:

> The devm_get_clk_from_child() function uses device-managed resources
> that are automatically cleaned up. The clk_put() call after
> devm_get_clk_from_child() is redundant and
> may lead to double-free issues.
> 
> Fixes: a54275f4ab20 ("bus: ti-sysc: Add quirk handling for external optional functional clock")
> Signed-off-by: Miaoqian Lin <linmq006@...il.com>
> ---
>  drivers/bus/ti-sysc.c | 1 -
>  1 file changed, 1 deletion(-)
> 
> diff --git a/drivers/bus/ti-sysc.c b/drivers/bus/ti-sysc.c
> index 9f624e5da991..5441b0739faa 100644
> --- a/drivers/bus/ti-sysc.c
> +++ b/drivers/bus/ti-sysc.c
> @@ -362,7 +362,6 @@ static int sysc_add_named_clock_from_child(struct sysc *ddata,
>  	cl->clk = clock;
>  	clkdev_add(cl);
>  
> -	clk_put(clock);
>  
>  	return 0;
>  }
I understand the double-free issue, but I have some questions to make
sure I understand it correctly what we are doing here. So lets ask the
possibly stupid questions and check assumptions:

- clk_hw hardware still lives after clk_put(), so we do not have
  problems normally here after that put when we do not remove the
  device?

- With your patch the put is delayed, so things live longer. So why
we do not use devm_clk_put() or avoid using devres at all here?

Regards,
Andreas

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ