[PATCH net] dpll: zl3073x: fix memory leak on pin registration failure

[PATCH net] dpll: zl3073x: fix memory leak on pin registration failure

[Ivan Vecera]

If zl3073x_dpll_pin_register() fails, the allocated pin is not yet
added to zldpll->pins list. The error path calls
zl3073x_dpll_pins_unregister() which only iterates pins on the list,
so the current pin is leaked. Free the pin before jumping to the error
label.

Fixes: 75a71ecc2412 ("dpll: zl3073x: Register DPLL devices and pins")
Signed-off-by: Ivan Vecera <ivecera@redhat.com>
---
 drivers/dpll/zl3073x/dpll.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/dpll/zl3073x/dpll.c b/drivers/dpll/zl3073x/dpll.c
index c95e93ef3ab0..d6232aa371be 100644
--- a/drivers/dpll/zl3073x/dpll.c
+++ b/drivers/dpll/zl3073x/dpll.c
@@ -1563,8 +1563,10 @@ zl3073x_dpll_pins_register(struct zl3073x_dpll *zldpll)
 		}
 
 		rc = zl3073x_dpll_pin_register(pin, index);
-		if (rc)
+		if (rc) {
+			zl3073x_dpll_pin_free(pin);
 			goto error;
+		}
 
 		list_add(&pin->list, &zldpll->pins);
 	}
-- 
2.53.0

Re: [PATCH net] dpll: zl3073x: fix memory leak on pin registration failure

[Petr Oros]

On 5/15/26 21:39, Ivan Vecera wrote:
> If zl3073x_dpll_pin_register() fails, the allocated pin is not yet
> added to zldpll->pins list. The error path calls
> zl3073x_dpll_pins_unregister() which only iterates pins on the list,
> so the current pin is leaked. Free the pin before jumping to the error
> label.
>
> Fixes: 75a71ecc2412 ("dpll: zl3073x: Register DPLL devices and pins")
> Signed-off-by: Ivan Vecera <ivecera@redhat.com>
> ---
>   drivers/dpll/zl3073x/dpll.c | 4 +++-
>   1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/dpll/zl3073x/dpll.c b/drivers/dpll/zl3073x/dpll.c
> index c95e93ef3ab0..d6232aa371be 100644
> --- a/drivers/dpll/zl3073x/dpll.c
> +++ b/drivers/dpll/zl3073x/dpll.c
> @@ -1563,8 +1563,10 @@ zl3073x_dpll_pins_register(struct zl3073x_dpll *zldpll)
>   		}
>   
>   		rc = zl3073x_dpll_pin_register(pin, index);
> -		if (rc)
> +		if (rc) {
> +			zl3073x_dpll_pin_free(pin);
>   			goto error;
> +		}
>   
>   		list_add(&pin->list, &zldpll->pins);
>   	}

Reviewed-by: Petr Oros <poros@redhat.com>

Re: [PATCH net] dpll: zl3073x: fix memory leak on pin registration failure

[Jakub Kicinski]

This is an AI-generated review of your patch. The human sending this
email says "Looks related enough to fix together"
---
dpll: zl3073x: fix memory leak on pin registration failure

This patch frees the freshly allocated pin when zl3073x_dpll_pin_register()
returns an error, since the pin has not yet been added to zldpll->pins and
would otherwise be missed by the unregister loop.

> diff --git a/drivers/dpll/zl3073x/dpll.c b/drivers/dpll/zl3073x/dpll.c
> index 6fd718696de0..a39dedac8b58 100644
> --- a/drivers/dpll/zl3073x/dpll.c
> +++ b/drivers/dpll/zl3073x/dpll.c
> @@ -1597,8 +1597,10 @@ zl3073x_dpll_pins_register(struct zl3073x_dpll *zldpll)
>  		}
>  
>  		rc = zl3073x_dpll_pin_register(pin, index);
> -		if (rc)
> +		if (rc) {
> +			zl3073x_dpll_pin_free(pin);
>  			goto error;
> +		}

[Medium]
Can the new zl3073x_dpll_pin_free(pin) call trigger a spurious warning
when zl3073x_dpll_pin_register() fails at the dpll_pin_get() step?

Looking at zl3073x_dpll_pin_register():

	pin->dpll_pin = dpll_pin_get(zldpll->dev->clock_id, index, THIS_MODULE,
				     &props->dpll_props, &pin->tracker);
	if (IS_ERR(pin->dpll_pin)) {
		rc = PTR_ERR(pin->dpll_pin);
		goto err_pin_get;
	}
	...
err_register:
	dpll_pin_put(pin->dpll_pin, &pin->tracker);
	pin->dpll_pin = NULL;
err_pin_get:
	fwnode_handle_put(pin->fwnode);
	pin->fwnode = NULL;
	zl3073x_pin_props_put(props);

	return rc;

On the err_pin_get path, pin->dpll_pin is left holding the ERR_PTR value
returned by dpll_pin_get() (only err_register clears it).

Then zl3073x_dpll_pin_free() does:

	WARN(pin->dpll_pin, "DPLL pin is still registered\n");
	kfree(pin);

Since an ERR_PTR is non-NULL, would this WARN fire on every dpll_pin_get()
failure (for example ENOMEM), producing a misleading "DPLL pin is still
registered" backtrace and panicking kernels booted with panic_on_warn=1?

Would it be appropriate to either set pin->dpll_pin = NULL in the
err_pin_get path of zl3073x_dpll_pin_register(), or change the WARN
condition in zl3073x_dpll_pin_free() to use !IS_ERR_OR_NULL(pin->dpll_pin)?

 \
  		list_add(&pin->list, &zldpll->pins);
  	}
-- 
pw-bot: cr

Re: [PATCH net] dpll: zl3073x: fix memory leak on pin registration failure

[Ivan Vecera]

On 5/19/26 2:05 AM, Jakub Kicinski wrote:
> This is an AI-generated review of your patch. The human sending this
> email says "Looks related enough to fix together"
> ---
> dpll: zl3073x: fix memory leak on pin registration failure
> 
> This patch frees the freshly allocated pin when zl3073x_dpll_pin_register()
> returns an error, since the pin has not yet been added to zldpll->pins and
> would otherwise be missed by the unregister loop.
> 
>> diff --git a/drivers/dpll/zl3073x/dpll.c b/drivers/dpll/zl3073x/dpll.c
>> index 6fd718696de0..a39dedac8b58 100644
>> --- a/drivers/dpll/zl3073x/dpll.c
>> +++ b/drivers/dpll/zl3073x/dpll.c
>> @@ -1597,8 +1597,10 @@ zl3073x_dpll_pins_register(struct zl3073x_dpll *zldpll)
>>   		}
>>   
>>   		rc = zl3073x_dpll_pin_register(pin, index);
>> -		if (rc)
>> +		if (rc) {
>> +			zl3073x_dpll_pin_free(pin);
>>   			goto error;
>> +		}
> 
> [Medium]
> Can the new zl3073x_dpll_pin_free(pin) call trigger a spurious warning
> when zl3073x_dpll_pin_register() fails at the dpll_pin_get() step?
> 
> Looking at zl3073x_dpll_pin_register():
> 
> 	pin->dpll_pin = dpll_pin_get(zldpll->dev->clock_id, index, THIS_MODULE,
> 				     &props->dpll_props, &pin->tracker);
> 	if (IS_ERR(pin->dpll_pin)) {
> 		rc = PTR_ERR(pin->dpll_pin);
> 		goto err_pin_get;
> 	}
> 	...
> err_register:
> 	dpll_pin_put(pin->dpll_pin, &pin->tracker);
> 	pin->dpll_pin = NULL;
> err_pin_get:
> 	fwnode_handle_put(pin->fwnode);
> 	pin->fwnode = NULL;
> 	zl3073x_pin_props_put(props);
> 
> 	return rc;
> 
> On the err_pin_get path, pin->dpll_pin is left holding the ERR_PTR value
> returned by dpll_pin_get() (only err_register clears it).
> 
> Then zl3073x_dpll_pin_free() does:
> 
> 	WARN(pin->dpll_pin, "DPLL pin is still registered\n");
> 	kfree(pin);
> 
> Since an ERR_PTR is non-NULL, would this WARN fire on every dpll_pin_get()
> failure (for example ENOMEM), producing a misleading "DPLL pin is still
> registered" backtrace and panicking kernels booted with panic_on_warn=1?
> 
> Would it be appropriate to either set pin->dpll_pin = NULL in the
> err_pin_get path of zl3073x_dpll_pin_register(), or change the WARN
> condition in zl3073x_dpll_pin_free() to use !IS_ERR_OR_NULL(pin->dpll_pin)?
> 
>   \
>    		list_add(&pin->list, &zldpll->pins);
>    	}

Will fix in v2.

Ivan