After device_initialize(), the lifetime of the embedded struct device
is expected to be managed through the device core reference counting.

In fsl_mc_device_add(), all failures after device_initialize() jump to
error_cleanup_dev, where mc_dev and its associated resources are freed
directly instead of releasing the device reference with
put_device(&mc_dev->dev). This bypasses the normal device lifetime
rules and may leave the reference count of the embedded struct device
unbalanced, resulting in a refcount leak.

The issue was identified by a static analysis tool I developed and
confirmed by manual review.

Fix this by using put_device(&mc_dev->dev) in the error path and let
fsl_mc_device_release() handle the final cleanup.

Fixes: bbf9d17d9875 ("staging: fsl-mc: Freescale Management Complex (fsl-mc) bus driver")
Cc: stable@vger.kernel.org
Signed-off-by: Guangshuo Li <lgs201920130244@gmail.com>
---
v2:
  - note that the issue was identified by my static analysis tool
  - and confirmed by manual review

 drivers/bus/fsl-mc/fsl-mc-bus.c | 6 +-----
 1 file changed, 1 insertion(+), 5 deletions(-)

diff --git a/drivers/bus/fsl-mc/fsl-mc-bus.c b/drivers/bus/fsl-mc/fsl-mc-bus.c
index 25845c04e562..6d132144ce25 100644
--- a/drivers/bus/fsl-mc/fsl-mc-bus.c
+++ b/drivers/bus/fsl-mc/fsl-mc-bus.c
@@ -905,11 +905,7 @@ int fsl_mc_device_add(struct fsl_mc_obj_desc *obj_desc,
 	return 0;
 
 error_cleanup_dev:
-	kfree(mc_dev->regions);
-	if (mc_bus)
-		kfree(mc_bus);
-	else
-		kfree(mc_dev);
+	put_device(&mc_dev->dev);
 
 	return error;
 }
-- 
2.43.0

On Mon, Apr 13, 2026 at 09:43:44PM +0800, Guangshuo Li wrote:
> After device_initialize(), the lifetime of the embedded struct device
> is expected to be managed through the device core reference counting.
> 
> In fsl_mc_device_add(), all failures after device_initialize() jump to
> error_cleanup_dev, where mc_dev and its associated resources are freed
> directly instead of releasing the device reference with
> put_device(&mc_dev->dev). This bypasses the normal device lifetime
> rules and may leave the reference count of the embedded struct device
> unbalanced, resulting in a refcount leak.
> 
> The issue was identified by a static analysis tool I developed and
> confirmed by manual review.
> 
> Fix this by using put_device(&mc_dev->dev) in the error path and let
> fsl_mc_device_release() handle the final cleanup.
> 
> Fixes: bbf9d17d9875 ("staging: fsl-mc: Freescale Management Complex (fsl-mc) bus driver")
> Cc: stable@vger.kernel.org
> Signed-off-by: Guangshuo Li <lgs201920130244@gmail.com>
> ---
> v2:
>   - note that the issue was identified by my static analysis tool
>   - and confirmed by manual review
> 
>  drivers/bus/fsl-mc/fsl-mc-bus.c | 6 +-----
>  1 file changed, 1 insertion(+), 5 deletions(-)
> 
> diff --git a/drivers/bus/fsl-mc/fsl-mc-bus.c b/drivers/bus/fsl-mc/fsl-mc-bus.c
> index 25845c04e562..6d132144ce25 100644
> --- a/drivers/bus/fsl-mc/fsl-mc-bus.c
> +++ b/drivers/bus/fsl-mc/fsl-mc-bus.c
> @@ -905,11 +905,7 @@ int fsl_mc_device_add(struct fsl_mc_obj_desc *obj_desc,
>  	return 0;
>  
>  error_cleanup_dev:
> -	kfree(mc_dev->regions);
> -	if (mc_bus)
> -		kfree(mc_bus);
> -	else
> -		kfree(mc_dev);
> +	put_device(&mc_dev->dev);
>  
>  	return error;
>  }
> -- 
> 2.43.0
>

Wasn't this issue already fixed by the following commit?

 commit 52f527d0916bcdd7621a0c9e7e599b133294d495 (tag: soc_fsl-6.20-1)
 Author: Haoxiang Li <lihaoxiang@isrc.iscas.ac.cn>
 Date:   Sat Jan 24 18:20:54 2026 +0800

     bus: fsl-mc: fix an error handling in fsl_mc_device_add()

     In fsl_mc_device_add(), device_initialize() is called first.
     put_device() should be called to drop the reference if error
     occurs. And other resources would be released via put_device
     -> fsl_mc_device_release. So remove redundant kfree() in
     error handling path.

     Fixes: bbf9d17d9875 ("staging: fsl-mc: Freescale Management Complex (fsl-mc) bus driver")
     Cc: stable@vger.kernel.org
     Reported-by: Dan Carpenter <dan.carpenter@linaro.org>
     Closes: https://lore.kernel.org/all/b767348e-d89c-416e-acea-1ebbff3bea20@stanley.mountain/
     Signed-off-by: Su Hui <suhui@nfschina.com>
     Suggested-by: Christophe Leroy (CS GROUP) <chleroy@kernel.org>
     Signed-off-by: Haoxiang Li <lihaoxiang@isrc.iscas.ac.cn>
     Reviewed-by: Ioana Ciornei <ioana.ciornei@nxp.com>
     Link: https://lore.kernel.org/r/20260124102054.1613093-1-lihaoxiang@isrc.iscas.ac.cn
     Signed-off-by: Christophe Leroy (CS GROUP) <chleroy@kernel.org>


What tree are you using?

Ioana

Hi Ioana,

Thanks for reviewing.

On Wed, 15 Apr 2026 at 17:38, Ioana Ciornei <ioana.ciornei@nxp.com> wrote:
>
> What tree are you using?
>
> Ioana

I was using v6.19-rc8-214-ge7aa57247700 when I found this issue.

From the commit you pointed out, it seems the problem has already been
fixed upstream. Sorry for the duplicate report, and thanks again for
catching this.

Best regards,
Guangshuo