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

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

On 5/15/26 21:39, Ivan Vecera wrote:

Reviewed-by: Petr Oros <redacted>

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.

[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

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.

quoted

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